`/kernel-bot` build should cancel in-progress builds for the same PR

[moon-bot-app]

Problem

When a /kernel-bot ... command that involves a build step is fired from a PR comment, it schedules a new build run but the already in-progress build run for the same PR is not cancelled. Both keep running in parallel.

Example: on #1031, run 30332005356 (the build run) had already succeeded, while the build run triggered by this /kernel-bot comment was still running long after.

Expected: the newer /kernel-bot-triggered build supersedes any in-flight build for the same PR (+ kernel/platform), so we save runner resources and get results faster.

Likely cause

The build workflows do declare concurrency, e.g. in .github/workflows/build.yaml (same in build-mac.yaml / build-windows.yaml):

concurrency:
  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
  cancel-in-progress: true

But these workflows are triggered via workflow_dispatch (from .github/scripts/dispatch.py), so github.head_ref is empty and the group falls back to github.run_id, which is unique per run. The result is a concurrency group of size 1 — cancel-in-progress can never cancel anything. The pull_request-triggered build-pr-dispatch.yaml has the same expression, but there head_ref is populated, which is why push-triggered builds do dedupe and dispatch-triggered ones don't.

Possible fix

Make the concurrency group derive from the dispatch inputs rather than head_ref, e.g. something like:

concurrency:
  group: ${{ github.workflow }}-${{ inputs.pr_number || github.head_ref || github.run_id }}-${{ inputs.kernel_name }}
  cancel-in-progress: true

(exact key TBD — probably PR number + kernel name + backend/platform, so unrelated kernels on the same PR don't cancel each other). Alternatively, have dispatch.py explicitly cancel matching in-progress runs for the PR before dispatching (it already has actions: write).

---

Requested by Sayak Paul - Slack thread - Agent trace