Jens-G opened a new pull request, #3895:
URL: https://github.com/apache/thrift/pull/3895

   > **Stacked on [#3893](https://github.com/apache/thrift/pull/3893) 
(THRIFT-6310), which is stacked on 
[#3894](https://github.com/apache/thrift/pull/3894) (THRIFT-6312).** Review 
those first; this branch contains both.
   
   Every release ships a prebuilt Windows compiler as a bare `thrift.exe`. 
There is nothing to install — whoever downloads it decides where to put it and 
how to get it onto `PATH`.
   
   This adds a Windows installer built with [Inno 
Setup](https://jrsoftware.org/isinfo.php), which is preinstalled on the GitHub 
Windows runner images.
   
   ## What it does *not* do
   
   It does not publish anything, and it asks for no write permission. That is 
deliberate, and it follows from treating the installer as a real release 
artifact rather than a convenience download:
   
   The installer goes to `dist.apache.org` with a detached GPG signature, 
alongside the tarball and `thrift.exe`. That means the file the vote covers has 
to be signed by a release manager — which has to happen *before* the vote, long 
before a GitHub release exists. A workflow firing on `release: published` could 
only ever produce a different, unsigned binary with the same name.
   
   So the split is: **CI builds and tests, the release manager signs and 
publishes.** `doc/ReleaseManagement.md` now covers building the installer, 
signing it, naming it in the `[VOTE]` e-mail next to the existing entries, and 
attaching *the voted file itself* to the GitHub release rather than a rebuild.
   
   If you would rather have it auto-attached to the GitHub release as an 
unsigned convenience artifact instead, that is a small change — say the word.
   
   ## The workflow
   
   `.github/workflows/windows-packages.yml`, on `pull_request` (paths) and 
`workflow_dispatch`:
   
   1. builds the compiler with `-DBUILD_LIBRARIES=OFF -DWITH_MT=ON`, Release;
   2. asserts it is self-contained, with the script from #3893;
   3. packages it;
   4. installs and uninstalls the result;
   5. reports the SHA-256 in the job summary and uploads the installer as an 
artifact, kept 14 days.
   
   Step 5 is what a release manager uses: run it against the release branch 
from the Actions tab, download `windows-installer`, sign it. Or build it 
locally with `build/windows/build-installer.ps1`, which is documented too.
   
   ## The installer
   
   - **No version in `thrift.iss`.** Version, compiler path and output 
directory all arrive on the `ISCC` command line, so `build/veralign.sh` gains 
nothing new to keep in step.
   - **Per-user by default**, no elevation. An administrator can still install 
for all users from the wizard or with `/ALLUSERS`.
   - **`AppId` is a fixed GUID** and must never change, or an upgrade would 
turn into a second installation. There is a comment saying so.
   - Ships `LICENSE` and `NOTICE` next to the executable.
   - Optionally adds the install directory to `PATH`.
   
   ## Why there is a test for a `PATH` edit
   
   Inno Setup can append to `PATH` on its own — `{olddata}` with 
`preservestringtype`, so Inno does the registry read and write and 
`%SystemRoot%` does not get baked in. But it cannot *undo* it. Removing the 
entry on uninstall is hand-written Pascal in `thrift.iss`, and code that edits 
someone's `PATH` gets one shot at being right.
   
   `installer/test-installer.ps1` drives a real silent install and uninstall 
and checks:
   
   - the compiler is installed, runs, and reports the expected version;
   - `LICENSE` and `NOTICE` are there;
   - the install directory landed on `PATH`;
   - after uninstall it is off `PATH` again;
   - **and every other entry survived.**
   
   For that last point the test appends a sentinel entry *behind* the Thrift 
one before uninstalling, so the uninstaller has to cut an entry out of the 
middle of the list rather than off the end — the case where an off-by-one in 
the index arithmetic would either eat a neighbour or leave a stray separator. I 
verified the four positions (first, middle, last, only) independently before 
writing the Pascal.
   
   ## Notes
   
   - No new third-party Actions. `ISCC.exe` is invoked directly; only 
`actions/checkout` and `actions/upload-artifact` are used, both already in this 
repo.
   - `zizmor` is clean on the new workflow.
   
   JIRA: [THRIFT-6311](https://issues.apache.org/jira/browse/THRIFT-6311)
   
   🤖 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]

Reply via email to