Jens-G opened a new pull request, #3996: URL: https://github.com/apache/thrift/pull/3996
[THRIFT-6400](https://issues.apache.org/jira/browse/THRIFT-6400) The `.NET tool` workflow built `thrift.exe` from the release tag and packed that build. A new build of the same source is not the same bytes, so `Apache.Thrift.Compiler` did not carry the `thrift-<version>.exe` the release vote covered. The compiler in the published 0.25.0 package has SHA-256 `3d3f2e8a…03648`, the voted `thrift-0.25.0.exe` has `9e1cb466…af08e`. #3985 (THRIFT-6397) made the Windows installer package the voted executable, and this does the same for the .NET tool. **Changes** - `dotnet-tool.yml` gets a `voted-compiler` job, taken over from `windows-packages.yml`. On a release it: - runs `get-voted-compiler-tests.ps1`; - fetches `thrift-<version>.exe` from `dist/release` with `get-voted-compiler.ps1`. Every checksum must match, and the signature must be a `GOODSIG` against `KEYS`; - collects the `LICENSE` and `NOTICE` of the release tag. The `pack` job packs that file. If the fetch or a check fails, `pack` is skipped and nothing is published. - A manual run takes a new `compiler_url` input and packs the executable at that URL, for example a release candidate's on dist/dev. A manual run never publishes. The input exists so that the voted path can run on a Windows runner without a release. - Pull requests, and manual runs without `compiler_url`, still build the compiler from source. - `test-dotnet-tool.ps1` gets `-ExpectedSha256`, which the workflow uses to check that the `thrift.exe` in the package is the file it packed. The run summary names the compiler's source and both hashes. - On a release, the version of the voted executable must match the tag. The existing check that the tag matches `CMakeLists.txt` stays. - The README shown on nuget.org (Provenance), `build/windows/README.md` and the `[nuget]` entry in `doc/ReleaseManagement.md` describe it. **Verification** - `test-dotnet-tool.ps1` in `mcr.microsoft.com/dotnet/sdk:8.0`, which takes the test's Linux path: - The published `apache.thrift.compiler.0.25.0.nupkg` from nuget.org, with `-ExpectedSha256 9e1cb466…`, **fails** "the bundled compiler is the expected file" (`3d3f2e8a…`): 1 of 19 checks. - `get-voted-compiler.ps1 -Url https://dist.apache.org/repos/dist/release/thrift/0.25.0/thrift-0.25.0.exe` passes: the SHA-256 matches and the signature is good. Packed with `build-dotnet-tool.ps1 -SourceRoot` holding the `LICENSE` and `NOTICE` of `v0.25.0`, the package passes all 19 checks with `-ExpectedSha256 9e1cb466…`. - The same package with the other hash fails 1 of 19. - Without `-ExpectedSha256`, 18 checks pass and the hash check does not run. - actionlint reports nothing. zizmor (`--persona regular`, with a token) reports no findings, with the same single suppressed finding as on master. - Job plan, derived from the job conditions: | Run | voted-compiler | pack | publish | |---|---|---|---| | pull request | skipped | builds from source | skipped | | manual, no `compiler_url` | skipped | builds from source | skipped | | manual, `compiler_url` | runs | packs the download | skipped | | manual, download refused | fails | skipped | skipped | | release | runs | packs the `dist/release` exe | runs, except for a pre-release | | release, download refused or the checks fail their tests | fails | skipped | skipped | Pull request CI exercises only the build-from-source path, including the new hash check on the Windows runner. The voted path first runs on a Windows runner when the workflow is started with `compiler_url`. After the merge, a manual run with `compiler_url` set to `https://dist.apache.org/repos/dist/release/thrift/0.25.0/thrift-0.25.0.exe` covers it and publishes nothing. The 0.25.0 package on nuget.org cannot be replaced, so the change applies from the next release. This PR and #3995 touch different sections of `build/windows/README.md` and `doc/ReleaseManagement.md`, and they merge without conflict in either order. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
