fix(ci): wait-for-deploy unshallows the clone when git log returns empty #100

Merged

nrupard merged 1 commit from fix/e2e-wait-deploy-unshallow into main

2026-06-05 17:35:15 +02:00

nrupard commented

2026-06-05 17:34:30 +02:00

Owner

Summary

Post-merge E2E run for PR #99 (the deploy-sync gate fix) failed at Wait for staging to serve this commit with:

Could not resolve build-trigger SHA: Error: No commit at-or-before d47d72aaa1 touches any build-trigger path.

The same git log -1 --format=%H d47d72a -- src crates migrations ... returns 52742c6 on a full local clone, so the cause is the Forgejo runner's actions/checkout shipping a shallow clone even with fetch-depth: 0 set.

Fix

Have wait-for-deploy.mjs self-heal: if the build-trigger query returns empty AND git rev-parse --is-shallow-repository reports true, run git fetch --unshallow origin and retry once. On a definitive miss, the error now includes clone depth and shallow state so the next failure is faster to diagnose. fetch-depth: 0 in the workflow stays as the primary path; this is the belt-and-suspenders fallback.

Test plan

Merge to main; the next E2E run resolves a build-trigger SHA (either GITHUB_SHA itself if build-relevant, or an ancestor) and proceeds past the deploy-sync gate.

## Summary Post-merge E2E run for PR #99 (the deploy-sync gate fix) failed at `Wait for staging to serve this commit` with: > Could not resolve build-trigger SHA: Error: No commit at-or-before d47d72aaa1a40946d2fedc0a4599828fbb025195 touches any build-trigger path. The same `git log -1 --format=%H d47d72a -- src crates migrations ...` returns `52742c6` on a full local clone, so the cause is the Forgejo runner's `actions/checkout` shipping a shallow clone even with `fetch-depth: 0` set. ## Fix Have `wait-for-deploy.mjs` self-heal: if the build-trigger query returns empty AND `git rev-parse --is-shallow-repository` reports true, run `git fetch --unshallow origin` and retry once. On a definitive miss, the error now includes clone depth and shallow state so the next failure is faster to diagnose. `fetch-depth: 0` in the workflow stays as the primary path; this is the belt-and-suspenders fallback. ## Test plan - [ ] Merge to main; the next E2E run resolves a build-trigger SHA (either GITHUB_SHA itself if build-relevant, or an ancestor) and proceeds past the deploy-sync gate.

nrupard added 1 commit

2026-06-05 17:34:30 +02:00

fix(ci): wait-for-deploy unshallows the clone when git log returns empty

Create release / Create release from merged PR (pull_request) Has been skipped

Details

Check / fmt + clippy + compile + tests (pull_request) Successful in 1m25s

Details

efea598f6b

The post-merge E2E run on d47d72a (which was a doc/test-only commit on top of build-relevant ancestors) failed the new deploy-sync gate with "No commit at-or-before ... touches any build-trigger path", even though that commit has src/, crates/, etc throughout its ancestry. Running the same `git log` invocation locally on a full clone returns the right SHA, so the cause is the Forgejo runner's actions/checkout shipping a shallow clone despite `fetch-depth: 0`.

Have the script self-heal: if the build-trigger query returns empty AND `git rev-parse --is-shallow-repository` reports true, run `git fetch --unshallow origin` and retry once. On a definitive miss, include the observed clone depth and shallow state in the error so the next failure is easier to diagnose. The fetch-depth: 0 hint in the workflow stays as the primary path; this is the fallback.

#PMS-140