Jens-G opened a new pull request, #3897: URL: https://github.com/apache/thrift/pull/3897
> **Stacked on [#3895](https://github.com/apache/thrift/pull/3895) (THRIFT-6311) → [#3893](https://github.com/apache/thrift/pull/3893) → [#3894](https://github.com/apache/thrift/pull/3894).** It describes the installer #3895 produces. Review those first; this branch contains them. Windows has a package manager and the Thrift compiler is not in it. ```shell winget install Apache.Thrift ``` ## The identifier `Apache.Thrift` is free. I swept the whole `winget-pkgs` manifest tree — 695k paths — and there is no Thrift manifest anywhere. `Apache` is the publisher folder the ASF already uses there, for Directory Studio, Groovy, NetBeans and OpenOffice. Two decoys live in the same folder and are *not* the ASF: `ApacheFriends` (XAMPP) and `ApacheLounge` (third-party httpd builds). ## Why the manifest points at the archive `InstallerUrl` has to keep resolving for as long as the manifest is in `winget-pkgs` — including for old versions, which stay there. `downloads.apache.org` only carries the *current* release, so a manifest naming it stops working at the next release and takes every older Thrift version with it. `archive.apache.org` is permanent. That is what makes this a **post-release** step: it cannot run until the release is promoted to `dist.apache.org` *and* the archive has picked it up. Same wait the Docker Official Image update already has, and `doc/ReleaseManagement.md` now says so and how to re-run it. The checksum is computed from the file downloaded from that exact URL, so the manifest cannot claim a checksum the published file does not have. ## What is checked, and where Two different questions, so two different checks: - **`winget/validate_manifests.py`** — do the rendered manifests match the WinGet **JSON schemas**? It reads the `ManifestType`/`ManifestVersion` out of each file and fetches the matching schema from Microsoft, so it follows the manifests instead of pinning a version here. Without this, a mistake is found only after the PR against `winget-pkgs` is already open. I ran this against the real published schemas: the three manifests validate. I also confirmed it *fails* properly — a bad `InstallerType`, a malformed `InstallerSha256` and a missing `defaultLocale` manifest are each reported. - **`winget/test-winget-manifests.ps1`** — does the renderer do its job? Values land where they belong; **no placeholder survives** into a file that would be submitted verbatim; output is UTF-8 without a BOM and with LF endings; a malformed version, checksum or date is refused. 18 checks, no network needed. Both run in CI, including on pull requests, where the manifests are rendered with an obviously fake checksum so the templates and the schema check are still exercised. ## Submission `wingetcreate`, which forks `winget-pkgs` itself — no fork setup on our side. It needs a **classic** PAT with `public_repo` scope; fine-grained tokens are not supported. It is read from `WINGET_CREATE_GITHUB_TOKEN` rather than passed as `--token`, which is what Microsoft's own release workflows do so it cannot land in a log. **Needed before the first release:** a secret `WINGET_TOKEN` in the `release` environment. Without it nothing breaks: the manifests are still rendered, validated and uploaded as an artifact, and the run prints a warning plus the exact command to submit them by hand. I chose that over failing the release workflow over a missing secret. ## Notes - The render/validate job runs on `ubuntu-latest`; only the submission needs Windows, because `wingetcreate` is Windows-only. - One installer entry, `Scope: user` — the installer is per-user by default. A machine-scope entry using `/ALLUSERS` can be added later if wanted. - `ProductCode` is `{AppId}_is1`, Inno Setup's uninstall key. The `AppId` is fixed in `thrift.iss` and must never change; both files say so. - `zizmor` is clean on the new workflow. JIRA: [THRIFT-6314](https://issues.apache.org/jira/browse/THRIFT-6314) 🤖 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]
