ci: skip the redundant push re-run of an already-gated SHA #435

Merged

hexajon merged 1 commit from ci/sha-dedup-push-rerun into main

2026-08-17 20:44:00 +00:00

hexajon commented

2026-08-17 20:28:16 +00:00

Owner

Under fast-forward-only merges, main's tip is the PR head commit, byte for byte. CI already ran the full gate on that exact SHA as a pull_request event, and that PR run is the cold one (no cache mount, #272), so it is the stronger check. Re-running the same jobs on the push event tested identical bytes in a warmer container for no added coverage. Commit 4e6fb7b shows it plainly: one SHA carrying both ci / gate (pull_request) and ci / gate (push) green, about 9 to 15 minutes of runner time spent twice.

This adds a small dedup check step to the gate and mcp-conformance jobs. On a push, it reads the public commit-status list for the SHA and, only if the matching (pull_request) context already succeeded, skips that job's heavy steps.

It fails safe:

It acts only on push. A pull_request run is the source of truth and is never skipped.
Any doubt leaves the job running: no prior success found, the status API unreachable, or jq missing. A direct-to-main push with no prior PR run still runs the full gate.
It trusts a prior CI run on the identical commit, not a local gate. The broader "should CI ever trust the local gate" question in #426 stays open and separate.

The required branch-protection checks are the (pull_request) contexts, so a skipped (push) job can never deadlock a merge. I left drift.yml's surface-diff as is: at about 14 seconds warm, the dedup step would cost close to what it saves on the single runner.

Verified locally: the YAML parses, the step wiring is correct, and the dedup shell is unit-tested under the Actions shell (bash -eo pipefail) across push and pull_request, match and no-match, and API-down. Every doubt yields a fail-safe re-run.

Refs #426.

Under fast-forward-only merges, main's tip is the PR head commit, byte for byte. CI already ran the full gate on that exact SHA as a `pull_request` event, and that PR run is the cold one (no cache mount, #272), so it is the stronger check. Re-running the same jobs on the `push` event tested identical bytes in a warmer container for no added coverage. Commit 4e6fb7b shows it plainly: one SHA carrying both `ci / gate (pull_request)` and `ci / gate (push)` green, about 9 to 15 minutes of runner time spent twice. This adds a small `dedup check` step to the `gate` and `mcp-conformance` jobs. On a `push`, it reads the public commit-status list for the SHA and, only if the matching `(pull_request)` context already succeeded, skips that job's heavy steps. It fails safe: - It acts only on `push`. A `pull_request` run is the source of truth and is never skipped. - Any doubt leaves the job running: no prior success found, the status API unreachable, or jq missing. A direct-to-main push with no prior PR run still runs the full gate. - It trusts a prior CI run on the identical commit, not a local gate. The broader "should CI ever trust the local gate" question in #426 stays open and separate. The required branch-protection checks are the `(pull_request)` contexts, so a skipped `(push)` job can never deadlock a merge. I left drift.yml's surface-diff as is: at about 14 seconds warm, the dedup step would cost close to what it saves on the single runner. Verified locally: the YAML parses, the step wiring is correct, and the dedup shell is unit-tested under the Actions shell (`bash -eo pipefail`) across push and pull_request, match and no-match, and API-down. Every doubt yields a fail-safe re-run. Refs #426.

hexajon added 1 commit

2026-08-17 20:28:16 +00:00

ci: skip the redundant push re-run of an already-gated SHA

drift / govulncheck (pull_request) Has been skipped

Details

drift / surface-diff (pull_request) Successful in 1m22s

Details

drift / forgejo-smoke (pull_request) Has been skipped

Details

ci / mcp-conformance (pull_request) Successful in 2m3s

Details

ci / gate (pull_request) Successful in 15m36s