ci: a rule for cancelling pull request runs whose commit is no longer the head (stale_runs.t27) #8144

Problem

The GitHub Actions queue is the swarm's bottleneck. Measured 2026-10-09 ~10:30 UTC on gHashTag/t27:

• 671 runs were queued and 16 were running.
• 69 of the queued runs were pull request runs whose commit was no longer the head of its pull request, or whose pull request was closed. Nothing will ever read their result, but each one still waits for a runner.
• 67 of them were cancelled by hand that day. The relief does not last: the next push to a pull request queues a full new set while the old set is still waiting.
• 43 workflows run on pull requests, and 19 of them have no concurrency: group: build-paper, catalog-count-gate, cli-tri, conformance-integrity-gate, coq-kernel, coq-proofs, emit-bitexact-gate, fix-carries-source, gf-wide-conformance, gf16-conformance, issue-gate, l1-traceability, loop-tools-gate, pack-index-consistency-gate, phi-loop-ci, pr-dashboard, seal-staleness-warn, vivado-synth, wasm-explorer.

An earlier pass (#4249, #4250) grouped the master push runs of ten gates. The pull request side was never done.

Spec

Write specs/ci/stale_runs.t27: the rule that decides, for one queued or running workflow run, whether to KEEP or CANCEL it. The rule lives in t27 so that a workflow can compile its generated C, the way spec-guards compiles gen/c/ci/affected.c. Nothing in the rule calls GitHub.

• run_action(event, head_is_current, pr_open, newest_on_branch, protected) returns RUN_KEEP or RUN_CANCEL.
• event is one of EV_PULL_REQUEST, EV_PULL_REQUEST_TARGET, EV_PUSH, EV_SCHEDULE, EV_DISPATCH.
• A pull request run is cancelled when its commit is no longer the head of its pull request, or when the pull request is closed or merged.
• A push run is cancelled when a newer run of the same workflow exists on the same branch.
• A scheduled or manually dispatched run is always kept.
• A protected run is always kept, whatever else holds: deploy, publish, release, or a workflow that writes outside CI.

Tests

t27c test-report specs/ci/stale_runs.t27. Every test names run_action, and every rule above is pinned by one test.

Acceptance criteria

• t27c test-report specs/ci/stale_runs.t27 prints FAIL 0 and vacuous passes 0 of N with N at least 6
• a test asserts that run_action(EV_PULL_REQUEST, false, true, true, false) is RUN_CANCEL and that the same call with head_is_current true is RUN_KEEP
• a test asserts that a pull request run whose pull request is closed is RUN_CANCEL, for both EV_PULL_REQUEST and EV_PULL_REQUEST_TARGET
• a test asserts that a push run that is not the newest on its branch is RUN_CANCEL, and the newest one is RUN_KEEP
• a test asserts that EV_SCHEDULE and EV_DISPATCH runs are RUN_KEEP with every other argument false
• a test asserts that a protected run is RUN_KEEP in each of the cancel cases above
• t27c gen-c specs/ci/stale_runs.t27 exits 0 and prints a C function named run_action

Follow-up (not for a bee: workflow files need the owner's label)

• A scheduled workflow, cancel-stale-runs.yml.
  • Every 10 minutes it compiles the generated C, lists the queued and running runs with gh api, and cancels the ones run_action marks RUN_CANCEL.
  • The deploy and publish workflows are passed in as protected.
  • It prints cancelled N of M.
• A concurrency: group for each of the 19 pull request workflows above:
  • group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }};
  • cancel-in-progress: ${{ github.event_name == 'pull_request' || github.event_name == 'pull_request_target' }}.
• Each workflow file needs an entry in tools/policy/foreign-exceptions.txt and the owner-approved-foreign label on its pull request.

Boundary

specs/ci/stale_runs.t27

User Scenarios

• Given a pull request workflow run queued on a commit that is no longer the head of its pull request, when run_action is evaluated with event=EV_PULL_REQUEST, head_is_current=false, pr_open=true, newest_on_branch=true, protected=false, then it returns RUN_CANCEL.
• Given a push workflow run on a branch where a newer run of the same workflow exists, when run_action is evaluated with event=EV_PUSH, head_is_current=true, pr_open=false, newest_on_branch=false, protected=false, then it returns RUN_CANCEL.
• Given a protected deploy workflow run that would otherwise be cancelled because its commit is stale, when run_action is evaluated with protected=true, then it returns RUN_KEEP regardless of other arguments.

Requirements

FR-001: The spec file specs/ci/stale_runs.t27 MUST define a function run_action(event, head_is_current, pr_open, newest_on_branch, protected) that returns either RUN_KEEP or RUN_CANCEL.

FR-002: For event in {EV_PULL_REQUEST, EV_PULL_REQUEST_TARGET}, run_action MUST return RUN_CANCEL when head_is_current is false or pr_open is false, unless protected is true.

FR-003: For event = EV_PUSH, run_action MUST return RUN_CANCEL when newest_on_branch is false, unless protected is true.

FR-004: For event in {EV_SCHEDULE, EV_DISPATCH}, run_action MUST return RUN_KEEP regardless of other arguments.

FR-005: When protected is true, run_action MUST return RUN_KEEP for all event types and all combinations of other arguments.

FR-006: The spec MUST compile to C via t27c gen-c specs/ci/stale_runs.t27 producing a C function named run_action.

FR-007: The spec MUST include at least six non-vacuous tests covering each rule above, and t27c test-report specs/ci/stale_runs.t27 MUST report FAIL 0 and vacuous passes 0 of N with N ≥ 6.