fix(ci): skip the diff-based audits on branch creation instead of guessing a base - #7034
fix(ci): skip the diff-based audits on branch creation instead of guessing a base#7034waleedlatif1 wants to merge 1 commit into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
PR SummaryLow Risk Overview When Checkout also drops Reviewed by Cursor Bugbot for commit dcf5863. Configure here. |
Greptile SummaryThe PR replaces the
Confidence Score: 4/5The PR should not merge until manual workflow dispatches handle their absent The new resolver assumes every non-PR, non-creation event supplies a push base SHA, but the workflow also declares Files Needing Attention: .github/workflows/test-build.yml
|
| Filename | Overview |
|---|---|
| .github/workflows/test-build.yml | Correctly skips audits for branch creation, but the revised event branching breaks the workflow's direct manual-dispatch path. |
Reviews (1): Last reviewed commit: "fix(ci): skip the diff-based audits on b..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| elif [ "${{ github.event.before }}" = "0000000000000000000000000000000000000000" ]; then | ||
| # Branch creation: nothing precedes this push, so there is no base to | ||
| # diff against. Say so and let the audits skip. Naming a commit here | ||
| # would audit that one commit while reporting on the whole push. | ||
| echo "::notice::Branch created — no preceding commit to diff against; skipping the diff-based audits." | ||
| echo "ref=" >> "$GITHUB_OUTPUT" | ||
| else | ||
| git fetch --depth=1 origin "${{ github.event.before }}" |
There was a problem hiding this comment.
When this workflow runs through its declared workflow_dispatch trigger, github.event.before is empty rather than the all-zero branch-creation value, so the resolver executes git fetch --depth=1 origin "", causing the base-resolution step and the manually dispatched test-build job to fail.
… guessing one Follow-up to #7033, which merged with this thread open. A push that creates a branch reports an all-zero `github.event.before`, and the fallback answered that with `HEAD~1` — auditing the single tip commit while reporting on the whole push. That is the same partial-audit-reported-as-complete failure #7033 set out to remove, one case further along. There is no correct base to substitute. Nothing precedes the push, and diffing the whole history would lint every migration ever written. So the audits skip with a `::notice::` naming the reason. A stated skip is honest; a partial audit wearing a green check is not. The same branch also covers `workflow_dispatch`, where `before` is empty rather than all-zero because there is no push payload at all. The guard has to test both — an empty `before` reaching the fetch would run `git fetch origin ""` and fail the job outright, which this workflow allows since it declares `workflow_dispatch`. Dropping the fallback drops its only consumer: `fetch-depth: 2` existed to give `HEAD~1` something to resolve to, and `before` is fetched by SHA, so the checkout returns to the default depth. Traced all four event shapes through the branch — PR, ordinary push, branch creation, manual dispatch — and verified both audits still pass against a raw SHA base.
dcf5863 to
f8607a5
Compare
1 participant
The finding
Correct. It is the same failure #7033 set out to remove — a partial audit reported as a complete one — one case further along.
Why there is no base to substitute
Nothing precedes a branch-creating push. The alternatives are both wrong:
HEAD~1audits one arbitrary commit and reports on the whole push.--allmode already exits 1 on this repo for exactly that reason.So the audits now skip, and say so:
A stated skip is honest. A partial audit wearing a green check is what this whole line of work exists to stop.
Reachability
Only by deleting and recreating
main,stagingordev— the three branches the push trigger covers, all of which exist. This closes a gap, not an incident, and I'd rather say that plainly than dress it up.It makes #7033 smaller
fetch-depth: 2existed solely to give theHEAD~1fallback something to resolve to. With the fallback gone its only consumer goes too, and sincebeforeis fetched by SHA the checkout returns to its default depth — untouched, as it was before #7033.Net −9 lines against #7033.
Verification
HEAD~1no longer appears anywhere in the workflowexit=0)if: steps.audit_base.outputs.ref != ''guard, so they cannot diverge on when they run