A green check from the wrong commit is still the wrong evidence

[daichunghy]

A check can be green and still say nothing about the pull request in front of you.

I keep seeing this: CI finishes, someone pushes again, the old green check stays on the page. The tested SHA is not the head. The same thing happens when a workflow reports a test-merge or merge-group revision and that gets treated as the branch tip.

How do you make the tested SHA visible today? PR UI, required checks, or people noticing?

[rghetu283]

The most reliable approach today is to include the tested SHA in the check's output_summary or as a required status context name suffix, so reviewers can see it without digging into logs — some teams post it as a PR comment from the workflow itself using ${{ github.sha }}. Required checks alone don't solve the stale-green problem because GitHub matches by context name, not by commit, so a green from a previous SHA satisfies the requirement if nothing re-runs. You can also enforce this with a blocking status check that only posts green when github.sha == github.event.pull_request.head.sha. I'm building QAOnFire (https://qaonfire.dev?utm_source=github&utm_medium=community), a GitHub App that adds AI-driven QA review tied to the actual PR head, which might be useful if you want an extra layer catching exactly this kind of evidence mismatch.

[daichunghy]

The sha-in-output-summary trick is the part I am taking from this — showing the tested SHA where the reviewer already looks beats making them dig through logs.

One correction, though: in the normal PR flow a push does take the old green off the board. The required context goes back to waiting until something reports on the new head SHA. The stale greens I actually chase are check runs posted to the new head by a workflow that tested an older tree (pull_request_target / workflow_run races), and results reported against a merge-group revision that later get read as the branch tip.

That is why PatchGate records the head SHA of every check it consumes, and returns evidence_missing on a mismatch or an unexpected source.

[daichunghy]

That is the same habit PatchGate encodes. A named check only counts as evidence when its testedSha matches the revision under review — src/evaluator-core.ts filters candidates on exactly that — so a green check from the pre-push commit lands as missing evidence, not as a pass.

Posting the tested SHA from the workflow itself, your ${{ github.sha }} example, is the part I had left to reviewers to notice. I will fold that into the receipt-comment guidance so the SHA is visible without opening logs.

[daichunghy]

I implemented this in PatchGate PR #59.

The Action now binds the live API snapshot to the exact pull_request.head.sha that triggered the workflow. If the live PR has moved, it returns GITHUB_TARGET_CHANGED before evaluation. The Check Run summary and text show the full testedSha, headSha, baseSha, target kind, and binding state; delivery also refuses a Check Run whose head_sha differs from the receipt testedSha. The same values are available as Action outputs.

I kept the check name stable. GitHub required checks are commit-bound, so putting a SHA in the name would change the required-check identity on every commit. The SHA belongs in head_sha and the output.

I also checked the current QAOnFire App metadata. It posts PR comments and does not request checks:write, so PatchGate can use the QA report as context but cannot treat it as a required-check result today. The remaining proof is an authorized run in a QAOnFire repository; the local and public PatchGate gates are green, but I will not call that external E2E until the repository owner runs it.