Context
The same Swatinium/rust-cache shared-key pattern that caused the build-python x86_64-gnu leg to restore host Ubuntu 22.04 build artifacts into a glibc 2.17 (manylinux2014) container — causing an ABI mismatch — still exists in two other places in release.yml:
build-napi Linux legs: the cross-compile jobs for x86_64-unknown-linux-gnu, x86_64-unknown-linux-musl, aarch64-unknown-linux-gnu, and aarch64-unknown-linux-musl use shared cache keys that do not include the target triple.build-python macOS pair: the x86_64-apple-darwin and aarch64-apple-darwin legs share the same broad cache key.
Why It Is Currently Benign
build-napi: every leg there builds on the host runner with the correct toolchain (cross-compilation is done at the linker level by zig cc or the cross GCC, not inside a container). The host and the artifact share the same glibc version, so no ABI mismatch arises from cache restoration.build-python macOS: both macOS legs run on the host, not inside a container, so there is no glibc boundary.
This was deliberately left out of PR #347, which targeted only the confirmed failing path (build-python Linux container legs). The fix — a one-line per-leg key: ${{ matrix.target }} — is low-risk and straightforward, but the change should be made intentionally and verified in CI.
Why It Matters
The failure mode is nondeterministic: it only manifests on a warm cache. A single green CI run does not prove the configuration is safe. If a future Swatinium/rust-cache version changes eviction heuristics, or if a scheduled workflow warms an unexpected leg's cache, the collision becomes load-bearing.
For build-napi, a cache collision that somehow serves a glibc artifact to the zig cc linker leg would produce a musl binary that silently links glibc — exactly the failure the musl readelf gate is there to catch, but the gate would still need to fire and be noticed.
Acceptance Criteria
References
Context
The same
Swatinium/rust-cacheshared-key pattern that caused thebuild-pythonx86_64-gnu leg to restore host Ubuntu 22.04 build artifacts into a glibc 2.17 (manylinux2014) container — causing an ABI mismatch — still exists in two other places inrelease.yml:build-napiLinux legs: the cross-compile jobs forx86_64-unknown-linux-gnu,x86_64-unknown-linux-musl,aarch64-unknown-linux-gnu, andaarch64-unknown-linux-musluse shared cache keys that do not include the target triple.build-pythonmacOS pair: thex86_64-apple-darwinandaarch64-apple-darwinlegs share the same broad cache key.Why It Is Currently Benign
build-napi: every leg there builds on the host runner with the correct toolchain (cross-compilation is done at the linker level by zig cc or the cross GCC, not inside a container). The host and the artifact share the same glibc version, so no ABI mismatch arises from cache restoration.build-pythonmacOS: both macOS legs run on the host, not inside a container, so there is no glibc boundary.This was deliberately left out of PR #347, which targeted only the confirmed failing path (
build-pythonLinux container legs). The fix — a one-line per-legkey: ${{ matrix.target }}— is low-risk and straightforward, but the change should be made intentionally and verified in CI.Why It Matters
The failure mode is nondeterministic: it only manifests on a warm cache. A single green CI run does not prove the configuration is safe. If a future
Swatinium/rust-cacheversion changes eviction heuristics, or if a scheduled workflow warms an unexpected leg's cache, the collision becomes load-bearing.For
build-napi, a cache collision that somehow serves a glibc artifact to the zig cc linker leg would produce a musl binary that silently links glibc — exactly the failure the musl readelf gate is there to catch, but the gate would still need to fire and be noticed.Acceptance Criteria
key: ${{ matrix.target }}(or a compound key including target and runner OS) to everySwatinium/rust-cachestep inbuild-napiand thebuild-pythonmacOS legs.RELEASING.mdor inlinerelease.ymlcomments to note that per-leg cache keys are intentional and must be preserved when updatingSwatinium/rust-cache.References
build-pythonLinux legs only