fix(ci): give push builds the parent commit their audits diff against

[waleedlatif1]

Unblocks the failing staging push build surfacing on the v0.8.11 release PR (#7032).

What is failing

✗ Migration safety check could not run.
  Cannot diff against 'HEAD~1'. The ref is missing, or was fetched without
  enough history for a merge-base.

Why

actions/checkout in the audit job sets no fetch-depth, so it defaults to 1 — a single-commit clone in which HEAD~1 does not resolve. Both diff-based audits use HEAD~1 as their base on push events, so neither has ever had a base to read.

Proven in a two-commit repo:

depth=1:  git rev-parse HEAD~1  → does not resolve
depth=2:  git rev-parse HEAD~1  → d73c984…   git diff HEAD~1 HEAD → f

This is #7022 doing its job, uncomfortably

Before #7022 the audit answered that failure with ✓ No new migrations to check and exit 0. It had never actually run on a push build — the green was a report about what it could see, not about the migrations.

#7022 made it say it cannot run rather than claim success, and the first push build after it merged said exactly that. The bug is the missing history; #7022 only stopped it being invisible.

The block-registry check has the identical input and reports ⚠ Could not diff against base ref — skipping. Visible, so it never blocked anything — and equally never ran on push.

Fix

fetch-depth: 2 on the audit job's checkout. That is the minimum that makes HEAD~1 name something, and on this repo's push events (squash merges) HEAD~1..HEAD is exactly the merged change.

Only the Lint and Test job changes. Build App keeps its depth-1 checkout — it does no diffing and a deeper fetch would slow it for nothing.

Verification

Both audits against HEAD~1 on a checkout with history:

✓ No new migrations to check.                exit=0
✓ Integration meta coverage check passed
✓ Sunset replacedBy check passed             exit=0

Since both already run on every PR against origin/<base>, and a push to staging carries the same content that just passed as a PR, neither should newly fail — they will simply run for the first time.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview	Aug 24, 2026 8:06am

[cursor]

PR Summary

Low Risk
CI checkout depth only; no application, auth, or data-path changes. Audits may now run on push for the first time.

Overview
Gives the Lint and Test job a two-commit checkout so push-event audits can actually resolve HEAD~1.

Default fetch-depth: 1 left no parent, so migration and block-registry checks never ran on push (they now fail instead of silently skipping). Build App is unchanged.

^{Reviewed by Cursor Bugbot for commit 4b3d90b. Configure here.}

[greptile-apps]

Greptile Summary

The PR centralizes resolution of the audit base and uses the pre-push SHA for ordinary push events.

• Fetches and exports one base ref for both diff-based audits.
• Uses github.event.before for normal pushes while retaining a depth-two HEAD~1 fallback for branch creation.
• The fallback leaves multi-commit branch-creation pushes partially unaudited.

Confidence Score: 4/5

The PR is not yet safe to merge because multi-commit branch-creation pushes can still bypass both diff-based audits for changes before the tip.

The previous reply, whose author is not shown in the supplied thread, says the tip-only audit issue was fixed, but an all-zero github.event.before still selects HEAD~1, leaving earlier commits in a new-branch push outside both audit ranges.

Files Needing Attention: .github/workflows/test-build.yml

Important Files Changed

Filename	Overview
.github/workflows/test-build.yml	Centralizes audit-base selection and fixes ordinary multi-commit pushes, but the all-zero before fallback still checks only the tip commit on branch creation.

_{Reviews (2): Last reviewed commit: "fix(ci): give push builds a base their a..." | Re-trigger Greptile}

[waleedlatif1]

@greptile