THRIFT-6399: Let the WinGet and Chocolatey workflows take the installer from the GitHub release

[Jens-G]

THRIFT-6399

The WinGet manifest and the Chocolatey package download the Windows installer from archive.apache.org, where it arrives through dist/release when the release vote covered it. When the vote did not cover it, as for 0.25.0, it is not there, and dist/release is not the place to add it afterwards. The GitHub release carries the installer as a convenience copy, built around the voted compiler, at a permanent URL that needs no login. A workflow artifact would not do: downloading one needs a GitHub login (anonymously, the API answers 401 and the web link 404), and it expires.

Changes

• build-winget-manifests.ps1 and build-chocolatey-package.ps1 get -InstallerSource. It is archive by default, or github, which points at https://github.com/apache/thrift/releases/download/v<version>/thrift-<version>-setup.exe. An unknown source, or a source together with -InstallerUrl, is refused. A failed download names what to check for the source in use: the archive's delay, or the asset on the GitHub release.

• winget.yml and chocolatey.yml get an installer_source choice input for manual runs, passed through env:. A release run has no inputs and keeps the archive.

• The Chocolatey package description no longer says that the installer comes from the Apache archive.

• doc/ReleaseManagement.md, Windows Packages: an installer the vote did not cover is no longer added to dist/release after the release. Instead:

  • make sure the copy on the GitHub release is built around the voted compiler; the release run's summary says which compiler it packaged;
  • run both workflows with installer_source set to github;
  • never replace that asset afterwards, because both package managers record its SHA-256.

  The step that overwrites the asset with the signed file from dist/release now applies only when the vote covered the installer. The Chocolatey and WinGet sections point to this section.

• build/windows/README.md and two comments in windows-packages.yml say the same.

Verification

• test-winget-manifests.ps1 and test-chocolatey-package.ps1: 23 checks each pass with pwsh 7.6, against 20 on master. On the unmodified builders the new checks fail. The suite stops at the GitHub URL check with "A parameter cannot be found that matches parameter name 'InstallerSource'", and that message matches neither refusal check.
• A real run against the 0.25.0 release. Its asset is now the installer built around the voted thrift-0.25.0.exe; see the ticket.
  • build-winget-manifests.ps1 -Version 0.25.0 -InstallerSource github -ReleaseDate 2026-09-30 downloads the asset and writes InstallerUrl: https://github.com/apache/thrift/releases/download/v0.25.0/thrift-0.25.0-setup.exe with InstallerSha256: 'C94286CB…FD666'. validate_manifests.py accepts all three manifests.
  • build-chocolatey-package.ps1 -Version 0.25.0 -InstallerSource github -StageOnly writes the same URL and checksum into chocolateyinstall.ps1.
• actionlint reports nothing. zizmor (--persona regular, with a token) reports no findings, with the same single suppressed finding as on master.

Run	Installer source	WinGet and Chocolatey
pull request	archive	placeholder checksum, no submit or push, as before
release	archive	download from the archive, then submit and push, as before
manual, installer_source = archive	archive	as before
manual, installer_source = github	github	download from the GitHub release, then submit and push

After this is merged, 0.25.0 needs one manual run of each workflow with installer_source set to github. The WinGet run also needs the release date 2026-09-30.

🤖 Generated with Claude Code