QVAC-24629 infra: cancel superseded CI runs on push and dispatch

[tobi-legan]

Problem

group: ${{ github.workflow }}-${{ github.head_ref && github.ref || github.run_id }}

head_ref is only set on pull_request. So on a push or a workflow_dispatch the group was unique per run, no two runs shared a group, and cancel-in-progress: true had nothing to act on — a re-dispatch stacked a second 8-job run instead of replacing the first.

Fix

concurrency:
  group: ${{ github.workflow }}-${{ github.event.pull_request.number || ((github.event.inputs.create_release == 'true' || github.ref_name == 'master') && github.run_id) || github.ref }}
  cancel-in-progress: true

event	group	behaviour
pull_request	PR number	supersedes
dispatch with create_release: true (any ref)	github.run_id	never cancels
push to master	github.run_id	never cancels
anything else (push to ci, plain dispatch)	github.ref	supersedes

runner-names-validate.yml had no block and gains one. 2 files.

Why the exemption keys on the publish predicate, not the branch

Every publish gate in build.yml has a branch-free disjunct:

release job (645)     if: (push && ref == refs/heads/master) || github.event.inputs.create_release == 'true'
docker push  (226)  push: (push && ref == refs/heads/master) || github.event.inputs.create_release == 'true'
Create release (683)  if: github.event_name == 'workflow_dispatch' || github.ref_name == 'master'
Upload release (692)  if: github.event_name == 'workflow_dispatch' || github.ref_name == 'master'

So a create_release: true dispatch publishes a GitHub release and pushes ghcr images from any ref, not just master. An earlier revision of this PR exempted only the branch, which left that path cancellable — Upload release creates the release and then loops uploadReleaseAsset one zip at a time, so a cancel in between leaves a published release with a partial asset set, and the tag-immutability ruleset means the tag cannot be deleted or moved to redo it cleanly.

Guarding cancel-in-progress on the input does not work either: it governs whether the incoming run cancels others, so it would stop a release run from cancelling other things while still letting a later push cancel the in-flight release.

github.event.inputs is null on push and PR events, so the added disjunct is inert there. ref_name matches the form the release steps themselves use, and also covers a tag named master.

Proof

Two workflow_dispatch runs of build.yml (create_release=false) on this branch, against the current tip:

run	created	result
34119894976	12:04:31Z	cancelled by the next dispatch
34119906908	12:04:39Z	took over, then cancelled by hand to free runners

The publish-exemption arm is deliberately not tested. Exercising it requires dispatching with create_release: true, which would cut a real GitHub release and push real ghcr images from a feature branch. The arm is verified by inspection against the four gates quoted above instead.

Static: all 5 workflow files parse, validate-runner-names.mjs ok (1 target, 1 workflow).

Not changed

check-approvals.yml (cancel-in-progress: false), security-baseline.yml (already correct), reusable-runner-names.yml (workflow_call — inherits the caller's group; its own would serialize every caller).

Pre-existing red check — not from this change, not fixed here

validate fails on node --test .github/scripts/test/runner-names.test.mjs: that file does not exist in this repo. Red since the runner-label catalog landed — master run 33856079417 and the PR that introduced it fail identically. Being handled separately; lib/runner-names.mjs has diverged from the ggml copy that has tests, so it is not a straight port.

QVAC-24629. Siblings: qvac-fabric-speech.cpp#219, qvac-fabric-llm.cpp#235, qvac-ext-ggml#83.

🤖 Generated with Claude Code

[github-actions]

Review Status

Current Status: ❌ PENDING
Approvals so far: none

Pending reviews: Needs 1 Management or Team Lead, and 1 more from Management, Team Lead, or Member.

[gianni-cor]

Reviewed the concurrency changes, including security considerations. Manual default-branch dispatch overlap is accepted behavior; no blocking issues found.