From 4fb8a49514affee55ab6d69d1181fb8c8f4291b6 Mon Sep 17 00:00:00 2001 From: Eric J Date: Wed, 29 Jul 2026 23:17:55 -0700 Subject: [PATCH] fix(ci): stop pushes to main cancelling each other's verify run `cancel-in-progress: true` is right for pull requests and wrong for `main`. On 2026-07-30 six PRs merged inside half an hour and the runs for 605a4cc and be5f592 were both cancelled by the merge that followed them, so two commits on the deploy branch carry no verdict of their own. Neither commit is actually unverified - each had a green `verify` on its own PR, and the ruleset will not let anything merge without one. But "green on the PR" and "green as it sits on main" are different claims, and only the second survives a merge into a `main` that has moved since the check ran. `strict_required_status_checks_policy` is false (see #60), which is precisely what makes that gap reachable rather than theoretical. Gated on `github.event_name` rather than on the ref, so it keeps cancelling for `pull_request` and stops for `push` - which also covers a future push trigger on any other branch. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01F3a2HLJ4beKARi7SPmaM54 --- .github/workflows/verify.yml | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/.github/workflows/verify.yml b/.github/workflows/verify.yml index 53195cbc..363d0de1 100644 --- a/.github/workflows/verify.yml +++ b/.github/workflows/verify.yml @@ -26,10 +26,22 @@ on: # So a run can be forced without an empty commit. workflow_dispatch: -# Superseded pushes to the same PR are pointless at ~2 minutes a run. +# Superseded pushes to the same PR are pointless at ~4 minutes a run, so those +# get cancelled. Pushes to `main` do NOT - `cancel-in-progress` there means a +# second merge kills the first one's run, and `main` is the branch the deploy +# ships from, so every commit on it should carry its own verdict. +# +# This is not hypothetical: on 2026-07-30 six PRs merged inside half an hour and +# the runs for `605a4cc` and `be5f592` were both cancelled by the merges that +# followed them. Neither commit is unverified in practice - each had a green +# `verify` on its own PR before the ruleset would let it merge - but "green on +# the PR" and "green as it sits on main" are different claims, and only the +# second one survives a rebase-free merge into a `main` that has since moved. +# `strict_required_status_checks_policy` is false, which is exactly what makes +# that gap reachable. concurrency: group: verify-${{ github.workflow }}-${{ github.ref }} - cancel-in-progress: true + cancel-in-progress: ${{ github.event_name == 'pull_request' }} # Minimum scope: the job only reads the tree. It writes no statuses, comments, # packages or releases, so nothing beyond `contents: read` is granted.