Skip to content

ci(rebuild-stale): git worktree add fails with 'invalid reference' on PR head sha #966

@joelteply

Description

@joelteply

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions