ci: supersede in-flight runs per ref — fixes 15-minute queue starvation

[dennys246]

Diagnosis

Jobs across five open PRs reported failure today. None of them ran.

unit-tests: conclusion=cancelled  runner_name=""  steps=0
created 16:21:10 → completed 16:36:11   (exactly 15m01s)

runner_name is empty — no machine was ever assigned. The jobs starved in the queue and were killed at a 15-minute limit, then surfaced as failure in gh pr checks, indistinguishable from real test failures. Five PRs read red while the only PR containing source changes was green. That's the dangerous part: a genuine failure could hide among the fake ones.

Not slowness. A healthy unit-tests job is ~12 min of real work (3m45s dependency install + 7m43s test run) and passes; lint and aarch64 resolve succeeded in the very same runs where unit-tests starved. Re-running the starved jobs with no code change turned them green.

Cause: the workflow had no concurrency group, so every push left its predecessor's run alive and competing for runners — N pushes to one branch demanded N times the slots, across five branches simultaneously.

Fix

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: ${{ github.ref != 'refs/heads/main' }}

cancel-in-progress is deliberately false on main — a superseded main run must still complete, because main's CI result is what the release gate and post-merge verification read. Only PR-branch runs are cancellable.

Not changed (deliberately)

• The dependency install (3m45s, includes llama-cpp-python) is a plausible trim, but removing optional deps changes which tests skip vs run — a coverage change that shouldn't ride a CI-infra fix.
• aarch64 resolve holds a slot 14–45 min and is a secondary contributor to demand; worth path-gating separately if starvation recurs.

🤖 Generated with Claude Code