Jens Geyer created THRIFT-6400:
----------------------------------
Summary: Package the voted compiler in the .NET tool
Key: THRIFT-6400
URL: https://issues.apache.org/jira/browse/THRIFT-6400
Project: Thrift
Issue Type: Improvement
Components: Build Process
Reporter: Jens Geyer
The {{.NET tool}} workflow builds {{thrift.exe}} from the release tag and packs
that build into {{Apache.Thrift.Compiler}}. Two builds of the same source are
not the same bytes, so the package on nuget.org does not contain the
{{thrift-<version>.exe}} that the release vote covered. THRIFT-6397 made the
Windows installer package the voted executable, and the .NET tool should do the
same. The 0.25.0 package was built from the tag, and a NuGet version cannot be
replaced, so this applies from the next release on.
h2. Change
* When the GitHub release is published, the workflow downloads
{{thrift-<version>.exe}} from {{dist/release}} with {{get-voted-compiler.ps1}},
which checks its checksums and its signature against {{KEYS}}. It packs that
file with the {{LICENSE}} and {{NOTICE}} of the release tag. If the download or
a check fails, nothing is packed: a release does not fall back to building its
own compiler.
* A manual run takes a new {{compiler_url}} input, as {{windows-packages.yml}}
does, and packs the executable at that URL, for example a release candidate's.
A manual run never publishes. The input is what lets the voted path 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 README shown on nuget.org, {{build/windows/README.md}} and
{{doc/ReleaseManagement.md}} describe it.
_Drafted with AI assistance (Claude Opus 5.5)._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
