[
https://issues.apache.org/jira/browse/THRIFT-6397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer updated THRIFT-6397:
-------------------------------
Description:
The Windows installer of a release has to contain the {{thrift.exe}} the vote
covered, and a new build of the same source is not the same bytes. The
{{Windows packages}} workflow can only package a compiler it builds itself, so
its installer cannot go to {{dist.apache.org}}, and the release manager has to
build that one by hand with Inno Setup. {{doc/ReleaseManagement.md}} offers the
workflow's artifact as an alternative while preparing a release candidate, but
that installer does not contain the executable that gets signed.
h2. Change
* {{build/windows/get-voted-compiler.ps1}} downloads a {{thrift-<version>.exe}}
from a release candidate's or a release's directory on {{dist.apache.org}},
together with its {{.asc}}, its {{.sha512}} or {{.sha256}} and {{KEYS}}. It
refuses the file unless every checksum matches and the signature is good and
made with a key from {{KEYS}}. Only {{dist.apache.org}} URLs naming a
{{thrift-<version>.exe}} are accepted. {{get-voted-compiler-tests.ps1}} tests
this with a throwaway key, in a job that runs every time the workflow runs.
* The {{Windows packages}} workflow packages that executable:
** when started from the Actions tab with the new {{compiler_url}} input, for
example with the executable of a release candidate on dist/dev;
** when the GitHub release is published, with the voted executable from
{{dist/release}}. The convenience copy it attaches to the release then contains
the voted compiler as well.
* The installer carries the {{LICENSE}} and {{NOTICE}} of the release tag, or
of the branch for a release candidate.
* {{test-installer.ps1}} gets {{-ExpectedSha256}}, which the workflow uses to
check that the installed {{thrift.exe}} is the very file it packaged.
* {{build-installer.ps1}} passes {{-SourceRoot}} to Inno Setup as an absolute
path. A relative one was resolved against {{thrift.iss}}.
* {{doc/ReleaseManagement.md}} and {{build/windows/README.md}} describe it.
* The vote mail template in {{doc/ReleaseManagement.md}} named the release
candidate's files {{thrift-1.0.0-rc0.\*}}, but the steps above it produce
{{thrift-1.0.0.\*}}, which is also what {{get-voted-compiler.ps1}} accepts. The
template now uses those names.
Pull requests, and manual runs without {{compiler_url}}, still build the
compiler from source.
_Drafted with AI assistance (Claude Opus 5.5)._
was:
The Windows installer of a release has to contain the {{thrift.exe}} the vote
covered, and a new build of the same source is not the same bytes. The
{{Windows packages}} workflow can only package a compiler it builds itself, so
its installer cannot go to {{dist.apache.org}}, and the release manager has to
build that one by hand with Inno Setup. {{doc/ReleaseManagement.md}} offers the
workflow's artifact as an alternative while preparing a release candidate, but
that installer does not contain the executable that gets signed.
h2. Change
* {{build/windows/get-voted-compiler.ps1}} downloads a {{thrift-<version>.exe}}
from a release candidate's or a release's directory on {{dist.apache.org}},
together with its {{.asc}}, its {{.sha512}} or {{.sha256}} and {{KEYS}}. It
refuses the file unless every checksum matches and the signature is good and
made with a key from {{KEYS}}. Only {{dist.apache.org}} URLs naming a
{{thrift-<version>.exe}} are accepted. {{get-voted-compiler-tests.ps1}} tests
this with a throwaway key, in a job that runs every time the workflow runs.
* The {{Windows packages}} workflow packages that executable:
** when started from the Actions tab with the new {{compiler_url}} input, for
example with the executable of a release candidate on dist/dev;
** when the GitHub release is published, with the voted executable from
{{dist/release}}. The convenience copy it attaches to the release then contains
the voted compiler as well.
* The installer carries the {{LICENSE}} and {{NOTICE}} of the release tag, or
of the branch for a release candidate.
* {{test-installer.ps1}} gets {{-ExpectedSha256}}, which the workflow uses to
check that the installed {{thrift.exe}} is the very file it packaged.
* {{build-installer.ps1}} passes {{-SourceRoot}} to Inno Setup as an absolute
path. A relative one was resolved against {{thrift.iss}}.
* {{doc/ReleaseManagement.md}} and {{build/windows/README.md}} describe it.
Pull requests, and manual runs without {{compiler_url}}, still build the
compiler from source.
_Drafted with AI assistance (Claude Opus 5.5)._
> Build the Windows installer around the voted compiler
> -----------------------------------------------------
>
> Key: THRIFT-6397
> URL: https://issues.apache.org/jira/browse/THRIFT-6397
> Project: Thrift
> Issue Type: Improvement
> Components: Build Process
> Reporter: Jens Geyer
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The Windows installer of a release has to contain the {{thrift.exe}} the vote
> covered, and a new build of the same source is not the same bytes. The
> {{Windows packages}} workflow can only package a compiler it builds itself,
> so its installer cannot go to {{dist.apache.org}}, and the release manager
> has to build that one by hand with Inno Setup. {{doc/ReleaseManagement.md}}
> offers the workflow's artifact as an alternative while preparing a release
> candidate, but that installer does not contain the executable that gets
> signed.
> h2. Change
> * {{build/windows/get-voted-compiler.ps1}} downloads a
> {{thrift-<version>.exe}} from a release candidate's or a release's directory
> on {{dist.apache.org}}, together with its {{.asc}}, its {{.sha512}} or
> {{.sha256}} and {{KEYS}}. It refuses the file unless every checksum matches
> and the signature is good and made with a key from {{KEYS}}. Only
> {{dist.apache.org}} URLs naming a {{thrift-<version>.exe}} are accepted.
> {{get-voted-compiler-tests.ps1}} tests this with a throwaway key, in a job
> that runs every time the workflow runs.
> * The {{Windows packages}} workflow packages that executable:
> ** when started from the Actions tab with the new {{compiler_url}} input, for
> example with the executable of a release candidate on dist/dev;
> ** when the GitHub release is published, with the voted executable from
> {{dist/release}}. The convenience copy it attaches to the release then
> contains the voted compiler as well.
> * The installer carries the {{LICENSE}} and {{NOTICE}} of the release tag, or
> of the branch for a release candidate.
> * {{test-installer.ps1}} gets {{-ExpectedSha256}}, which the workflow uses to
> check that the installed {{thrift.exe}} is the very file it packaged.
> * {{build-installer.ps1}} passes {{-SourceRoot}} to Inno Setup as an absolute
> path. A relative one was resolved against {{thrift.iss}}.
> * {{doc/ReleaseManagement.md}} and {{build/windows/README.md}} describe it.
> * The vote mail template in {{doc/ReleaseManagement.md}} named the release
> candidate's files {{thrift-1.0.0-rc0.\*}}, but the steps above it produce
> {{thrift-1.0.0.\*}}, which is also what {{get-voted-compiler.ps1}} accepts.
> The template now uses those names.
> Pull requests, and manual runs without {{compiler_url}}, still build the
> compiler from source.
> _Drafted with AI assistance (Claude Opus 5.5)._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
