INFRA
deploy-check stops red-flagging superseded CI runs
What changed
scripts/deploy-check.mjs now checks whether a cancelled verify-* run's SHA has been superseded by a newer origin/main tip before treating the cancellation as a hard failure; a genuine cancellation on the current tip still fails closed.
Why it changed
a concurrent push's concurrency-group cancel-in-progress cancels an older commit's in-flight run even though that commit's own checks never failed — the gate was mapping that cancellation to the same exit code as real CI red, risking a wrongful stop on green code. Filed as an AUDIT.md finding 2026-07-17.
const failed = runs.find((r) => r.status === 'completed' && r.conclusion !== 'success')
if (failed) {
+ // A `cancelled` run isn't necessarily a real failure: GitHub's
+ // concurrency group (`cancel-in-progress`) cancels an older
+ // commit's in-flight verify-* run when a newer commit lands on
+ // the same ref, even though the older commit's own checks never
+ // actually failed. Only fail-closed on a genuine cancellation —
+ // one where this SHA is still the branch tip, so nothing
+ // superseded it.
+ if (failed.conclusion === 'cancelled') {
+ let remoteTip = null
+ try {
+ remoteTip = execSync('git ls-remote origin refs/heads/main', { encoding: 'utf-8' })
+ .split('\t')[0]
+ .trim()
+ } catch {
+ // No network / no origin remote — fall through to fail-closed below.
+ }
+ if (remoteTip && remoteTip !== sha) {
+ console.error(`DEPLOY GATE: run cancelled — superseded by a newer commit on origin/main.`)
+ process.exit(2)
+ }
+ }
console.error(`DEPLOY FAILED (CI red).`)