Treat the multilib profile as a first-class CI and release artifact
alongside the standalone x64 and x86 profiles.
Add a build-multilib job that selects VARIANT=multilib, uses an
independent GitHub Actions cache scope, extracts the generated
self-extracting archive, and uploads it with a multilib-specific name.
Run it after the x64 job so the workflow retains the existing ordering
while allowing the x86 and multilib builds to proceed independently.
Make tagged releases wait for the multilib build as well. Build the
signed target with VARIANT=multilib, pass the same trusted-signing
credentials used by the other profiles, and pack the result as
w64devkit-multilib-<version>.7z.exe. The existing release glob then
publishes the signed multilib archive with the x64, x86, and source
artifacts.
Replace the loosely coordinated collection of x86 build arguments with
a single VARIANT selector. Define x64, x86, and multilib configuration
stages, then select the requested stage as the common cross-compiler
base. This keeps each supported configuration closed and prevents
callers from combining incompatible architecture settings.
Make x64 the default standalone profile. It targets
x86_64-w64-mingw32, disables GCC multilib support, builds only the
64-bit CRT, and omits the secondary 32-bit libraries and aliases.
Keep the standalone x86 behavior in its own profile. It targets
i686-w64-mingw32, retains the Pentium 4 default, enables only the
32-bit CRT, preserves the Windows XP header default and manifest
behavior, selects the 32-bit BusyBox and NSIS configurations, disables
zstd threading, and raises _WIN32_WINNT only while building CMake.
CMake and its bundled curl require at least Windows Vista APIs, so the
C and C++ flags continue to target Windows 7 without changing the
XP-oriented default of the installed toolchain.
Define multilib as an x86_64 compiler with GCC multilib enabled, both
CRT library sets installed, and the existing i686 forwarding aliases.
Use a dedicated EXTRA_32 setting for the secondary lib32 libraries,
winpthreads builds, thread support object, and aliases instead of
inferring that work from the spelling of a GCC configure option.
Expose independent CRT_LIB32 and CRT_LIB64 settings so each profile
selects exactly the runtime libraries it needs.
Pass the profile's CMake C and C++ flags directly rather than building
an optional argument list through shell positional parameters. Keep all
other profile-specific values next to the selected base stage, including
GCC architecture and manifest flags, BusyBox configuration, zstd
options, and NSIS target architecture.
Simplify multibuild.sh to pass only VARIANT to Docker. Add -m for the
multilib flavor, make -a build all three profiles, and remove the old
argument-file and Dockerfile-patch fallback paths. Update unsigned and
signed CI builds to select x64 or x86 directly, remove the obsolete
variant-x86.args bundle, and document the new build interface.
Verify all three profiles with docker build --check and complete cross
toolchain builds. Smoke-test x64 and x86 compilation, plus both the
64-bit compiler and i686 alias in the multilib profile. Also build the
x64 and x86 CMake targets to exercise both the empty and Windows 7
CMake flag configurations.
The variant patch no longer exists, so both x86 builds read
src/variant-x86.args into a step output, which build-push-action
accepts verbatim as its newline-delimited build-args input. The args
file remains the single definition of the variant.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sometimes, github actions cache is flaky and fails to export the cache.
Add ignore-error=true so a failing cache upload doesn't fail the CI run
and send a noisy email.
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.
