Two issues with non-release builds:
* git describe --always falls back to a commit SHA (e.g. abc123) on
branches without a recent tag. The old ${GIT_VERSION:1} stripped
the first character unconditionally -- fine for v2.8.0 -> 2.8.0,
but produced bc123 from a SHA. Use ${GIT_VERSION#v} instead so the
v is removed only when present.
* source.tar is a release artifact, not a CI artifact -- the source
Docker target build, the tar extraction, and the artifact upload
were running on every push. Gate the three steps on
startsWith(github.ref, 'refs/tags/') so non-release builds skip
them entirely.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign every PE inside the toolchain (~250 .exe and .dll), pack, then
sign the resulting self-extracting archive. All signing runs at
docker run time so the bulk of the build remains fully cacheable
and secrets never enter image layers.
Stage layout:
- dl-aas-sign / build-aas-sign: SHA-pinned source tarball with
vendored mbedtls + nlohmann/json, built with the base image's
Debian gcc.
- final: assembly only (drop the trailing 7z + CMD).
- signed (new): COPY aas-sign + sign-and-pack.sh, CMD runs the
script at docker run time. Reads AZURE_CLIENT_ID/TENANT_ID and
the GitHub OIDC env vars from -e flags.
- pack (new, default target): RUN 7z + CMD cat sfx archive.
Behaviorally identical to the old final.
The release workflow rebuilds --target signed for each arch
(reusing the same GHA cache scope as the unsigned pack build),
then docker runs the image to produce the signed package on
stdout.
Replace the windows-latest sign job (azure/login + azure/artifact-
signing-action) with a single Linux release job that uses
skeeto/aas-sign@v1.0.0. aas-sign handles the GitHub OIDC -> Azure
exchange directly, so the Azure CLI step is no longer needed and the
signed-artifact handoff to a separate release job collapses into one
step.
Also align the draft logic with sibling projects (dcmake, elfeed2,
stackcalc): tags vX.Y.Z-rcN are pipeline-test runs published as draft
prereleases; tags vX.Y.Z publish immediately.
archive: false makes upload-artifact override the user-supplied name:
parameter with the file's actual filename, so download-artifact can't
find artifacts named w64devkit-x64-unsigned, source-tarball, etc. Match
the artifact name to the filename so uploads and downloads agree.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
GitHub is going to remove node 20 from Actions:
https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/
All the actions versions have been upgraded to the latest major versions
available, ahead of the Node 20 deprecation
Move Azure signing from the old Trusted Signing preview action to
Artifact Signing v1, update azure/login to v3, and bump
actions/download-artifact to v8.
Split release into sign (windows-latest, environment: release) and
release jobs. Signs both .7z.exe via Azure Trusted Signing before
attaching to the release. Tags starting with v publish; other tags
produce draft releases for testing the pipeline.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Rename release archives from .exe to .7z.exe. Build the new source
Docker target and produce a reproducible source.tar of all upstream
tarballs, attached as both a CI artifact and a release asset.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
I rarely care about the status of the x86 builds, so this commit only
runs them if the x64 builds succeed. If the x64 build is successful but
the x86 build is not, the cache for the x64 build should kick in and the
x86 build should follow shortly after, if it's necessary to iterate on
it.
Updated the GitHub Actions workflow so x86 only runs after x64 succeeds.
Changed:
- Split the old matrix job into two explicit jobs: build-x64 and build-x86.
- Added needs: build-x64 on the x86 job, which enforces the dependency.
