The Test Shared libraries workflow fails when the separate V8 derivation is not available in Cachix and the workflow has no CACHIX_AUTH_TOKEN, as is the case for fork pull requests.
On a V8 cache miss, the aarch64-linux: Cache V8 build job builds V8 and uploads libv8-aarch64-linux.nar. The downstream shared-library matrix then contains two artifacts:
- The raw slim
.tar.gz artifact
libv8-aarch64-linux.nar
The first actions/download-artifact step in build-shared.yml does not specify an artifact name or pattern, so it downloads both. When multiple artifacts are selected, the action creates one directory per artifact. This places the raw tarball at:
tarballs/<tarball-name>.tar.gz/<tarball-name>.tar.gz
The subsequent command therefore matches the outer directory:
tar xzf tarballs/*.tar.gz -C "$RUNNER_TEMP"
and fails with:
tar (child): tarballs/node-v27.0.0-nightly...-slim.tar.gz: Cannot read: Is a directory
tar (child): Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error is not recoverable: exiting now
All aarch64 OpenSSL and BoringSSL matrix jobs fail before configuring, building, or testing Node.js.
Reproduction
The failure was observed in:
The triggering pull request changed configure.py, which participates in the separate V8 derivation. This produced a new derivation that was not in Cachix. The V8 prerequisite consequently built V8 and uploaded the local NAR artifact. Said PR no longer changes configure.py to get around the GHA issue.
The failure is deterministic whenever both conditions hold:
- The V8 derivation misses Cachix.
- The workflow cannot push to Cachix and uploads the local V8 NAR artifact.
Regression
This appears to have been introduced by #64423, which changed the tarball uploads to use archive: false and removed the previous name: tarballs filters.
cc @aduh95
The
Test Shared librariesworkflow fails when the separate V8 derivation is not available in Cachix and the workflow has noCACHIX_AUTH_TOKEN, as is the case for fork pull requests.On a V8 cache miss, the
aarch64-linux: Cache V8 buildjob builds V8 and uploadslibv8-aarch64-linux.nar. The downstream shared-library matrix then contains two artifacts:.tar.gzartifactlibv8-aarch64-linux.narThe first
actions/download-artifactstep inbuild-shared.ymldoes not specify an artifact name or pattern, so it downloads both. When multiple artifacts are selected, the action creates one directory per artifact. This places the raw tarball at:The subsequent command therefore matches the outer directory:
and fails with:
All aarch64 OpenSSL and BoringSSL matrix jobs fail before configuring, building, or testing Node.js.
Reproduction
The failure was observed in:
The triggering pull request changed
configure.py, which participates in the separate V8 derivation. This produced a new derivation that was not in Cachix. The V8 prerequisite consequently built V8 and uploaded the local NAR artifact. Said PR no longer changes configure.py to get around the GHA issue.The failure is deterministic whenever both conditions hold:
Regression
This appears to have been introduced by #64423, which changed the tarball uploads to use
archive: falseand removed the previousname: tarballsfilters.cc @aduh95