ci: always cancel in-progress shard runs to stop queue pile-up (#1792)

cancel-in-progress was false for pull_request events, so every synchronize (and every
master push) stacked another full 49-shard matrix in the queue instead of superseding the
prior run. Against the free-tier 20-concurrent-job cap this saturated the pool for hours —
fresh runs sat pending with 0 jobs dispatched (observed on PR #1789). Set cancel-in-progress
to true for all events so the latest commit's run supersedes the stale one and frees runners
immediately. The head run always completes (nothing newer supersedes it); only superseded
SHAs are cancelled, which is the correct signal.

Co-authored-by: franklinic <franklin@ivorycloud.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

Author: 3 people

.github/workflows/sonarcloud.yml

@@ -60,20 +60,21 @@ concurrency:
   # downstream check (branch-protection, PR mergeability, release tagging)
   # actually consumes. The intermediate-SHA loss is acceptable.
   group: build-${{ github.event.pull_request.number || github.ref }}
-  # cancel-in-progress is TRUE for push/master events (a newer master tip supersedes
-  # the prior in-flight run — only the latest tip needs a green signal, saves ~45min)
-  # but FALSE for pull_request events: a rapid synchronize must NOT kill an in-progress
-  # test-shard run, because cancelling mid-shard marks in-flight tests as FAILED and
-  # leaves the 49-shard matrix with no completed signal to verify a PR against
-  # (observed repeatedly on #1719: DQNAgent / FastConformer "failures" that pass
-  # locally were cancellation artifacts). GitHub still supersedes only PENDING runs in
-  # the group, so at most one run is queued per PR — bounded (≤1 in-progress + ≤1 pending),
-  # no matrix pile-up, so the extra runner time per PR is capped, not unbounded. The
-  # obvious alternative — keep cancel-in-progress: true but treat cancelled jobs as
-  # neutral in required checks — does not fit here: GitHub reports a cancelled required
-  # check as FAILING (not neutral), which is exactly the false-red branch-protection
-  # signal this setting exists to avoid.
-  cancel-in-progress: ${{ github.event_name != 'pull_request' }}
+  # cancel-in-progress is TRUE for ALL events (push AND pull_request). Only the latest
+  # commit on a branch/PR needs a green signal; letting a superseded 49-shard run keep
+  # executing just burns CI on a SHA nobody is on. With the GitHub free-tier 20-concurrent
+  # cap, NOT cancelling meant every synchronize/master push stacked another full matrix in
+  # the queue (≤1 in-progress + ≤1 pending PER PR, times many open PRs + master, saturated
+  # the pool for hours — the queue was so backed up that fresh runs sat pending with 0 jobs
+  # dispatched). Cancelling the in-flight run the moment a newer commit arrives frees the
+  # pool immediately, so the CURRENT tip's run actually gets runners.
+  #
+  # Trade-off accepted: a mid-matrix cancel marks that (now-stale) run's in-flight shards
+  # cancelled, and GitHub reports a cancelled required check as failing — but that is the
+  # SUPERSEDED SHA, not the head. The freshly-triggered run for the new tip is the
+  # authoritative signal every downstream check (branch protection, mergeability) consumes;
+  # its shards run to completion because nothing newer supersedes it.
+  cancel-in-progress: true
 
 env:
   DOTNET_SKIP_FIRST_TIME_EXPERIENCE: 1