Symptom
rebuild-stale-arm64 (and rebuild-stale-amd64 whenever it has to fire on a stale image) fails immediately with:
→ STARTUP_SHA_FULL resolved via GITHUB_EVENT_PATH .pull_request.head.sha: <sha>
→ Creating frozen worktree at /tmp/continuum-build-<short> (pinned at <sha>)
fatal: invalid reference: <sha>
##[error]Process completed with exit code 128.
Hit on PR #950 run 24927483127 at HEAD d98777e3d.
Root cause
actions/checkout@v4 with default settings on a pull_request event fetches refs/pull/<N>/merge (the synthetic merge sha) as a shallow clone. The PR head sha resolves correctly via .pull_request.head.sha (commit d98777e in scripts/push-current-arch.sh:140-143 lands the right value), but that commit object is not in the local git tree — it exists only as a remote ref.
git worktree add --detach <DIR> <SHA> requires the commit to be a local object.
Why amd64 didn't hit it this run
rebuild-stale-amd64 was skipped because the amd64 revision label already matched HEAD (BigMama's earlier push aligned it). The bug is latent for amd64 and will fire whenever amd64 drifts and rebuild is needed in CI.
Proposed fix
In scripts/push-current-arch.sh, before git worktree add, gate on git cat-file -e and git fetch the missing sha:
if ! git -C "$REPO_ROOT" cat-file -e "$STARTUP_SHA_FULL^{commit}" 2>/dev/null; then
echo "→ SHA $STARTUP_SHA_FULL not in local repo — fetching"
git -C "$REPO_ROOT" fetch --depth 1 origin "$STARTUP_SHA_FULL" 2>/dev/null \
|| git -C "$REPO_ROOT" fetch origin "$STARTUP_SHA_FULL" \
|| { echo "ERROR: cannot fetch sha $STARTUP_SHA_FULL"; exit 1; }
fi
Dev-machine path is unchanged (cat-file -e always succeeds on local HEAD). Only fires in CI when checkout's default fetch missed the sha.
Severity
Warning-only per the per-arch policy (#965), but the failure leaves arm64 stale labels and the merge sees a red rebuild-stale check. amd64 is currently green only because no rebuild was needed.
Related
Notes
Held back from committing the fix on PR #950 because the merge gate is currently green (verify-architectures + verify-after-rebuild both passing on amd64) and shipping a new commit would shift HEAD and trigger a fresh stale-label cycle. Better as a post-merge cleanup.
Symptom
rebuild-stale-arm64(andrebuild-stale-amd64whenever it has to fire on a stale image) fails immediately with:Hit on PR #950 run 24927483127 at HEAD
d98777e3d.Root cause
actions/checkout@v4with default settings on apull_requestevent fetchesrefs/pull/<N>/merge(the synthetic merge sha) as a shallow clone. The PR head sha resolves correctly via.pull_request.head.sha(commit d98777e in scripts/push-current-arch.sh:140-143 lands the right value), but that commit object is not in the local git tree — it exists only as a remote ref.git worktree add --detach <DIR> <SHA>requires the commit to be a local object.Why amd64 didn't hit it this run
rebuild-stale-amd64was skipped because the amd64 revision label already matched HEAD (BigMama's earlier push aligned it). The bug is latent for amd64 and will fire whenever amd64 drifts and rebuild is needed in CI.Proposed fix
In
scripts/push-current-arch.sh, beforegit worktree add, gate ongit cat-file -eandgit fetchthe missing sha:Dev-machine path is unchanged (
cat-file -ealways succeeds on local HEAD). Only fires in CI when checkout's default fetch missed the sha.Severity
Warning-only per the per-arch policy (#965), but the failure leaves arm64 stale labels and the merge sees a red rebuild-stale check. amd64 is currently green only because no rebuild was needed.
Related
Notes
Held back from committing the fix on PR #950 because the merge gate is currently green (verify-architectures + verify-after-rebuild both passing on amd64) and shipping a new commit would shift HEAD and trigger a fresh stale-label cycle. Better as a post-merge cleanup.