ci(.github): move concurrency to job level to avoid cancelling pending runs when skipped

[dclong]

Summary

• ci(merge-pr): move concurrency to job level to avoid cancelling pending runs when skipped

Changed files

Modified

• .github/workflows/merge-pr.yaml (+9/-7)

Commits

• 204ef4d ci(merge-pr): move concurrency to job level to avoid cancelling pending runs when skipped

[dclong]

Claude finished @dclong's task in 1m 16s —— View job

---

Code Review: PR #145

Change: Moves the concurrency block in .github/workflows/merge-pr.yaml from workflow level to job level (on merge_pull_request), keeping group: merge-pull-request / cancel-in-progress: false.

Analysis

This workflow is triggered frequently and by many event types (workflow_run completions, pull_request_review, hourly schedule, workflow_dispatch), but the merge_pull_request job only actually does work when its if: condition is true (workflow_run succeeded, or a non-workflow_run trigger).

With workflow-level concurrency, every triggered run enters the merge-pull-request group immediately, before the job's if: is evaluated. Per GitHub's documented concurrency semantics, when a run is queued (pending) behind an in-progress run, any previously pending run in the same group is canceled — regardless of cancel-in-progress. So a legitimate pending run (queued behind an in-progress merge, waiting to actually process the merge) could be canceled by an unrelated trigger whose job would ultimately be skipped anyway (e.g. an hourly cron tick, or a workflow_run completion for something irrelevant). That's a real bug: real work getting discarded in favor of a run that does nothing.

Moving concurrency to the job level fixes this correctly: a run whose if: evaluates to false never starts the job, so it never joins the concurrency group and can no longer cancel a genuinely pending merge run. Runs that do satisfy the if: condition still join the group and get the same serialization/queueing behavior as before (cancel-in-progress: false, so an in-progress merge is never cancelled mid-flight).

I verified:

• The YAML indentation places concurrency: correctly as a sibling of if:/uses:/with:/secrets: under the merge_pull_request job (valid job-level property).
• concurrency at the job level is fully supported for jobs that call a reusable workflow via uses:.
• No other parts of the file were affected; the extensive existing comments already document the rationale for the if: gate and the overall trigger design, and the new job-level comment accurately describes the reasoning above.

Verdict: No correctness bugs or blocking issues found. This is a small, well-reasoned, well-documented CI fix that closes a real race condition without changing behavior for the runs that actually perform merges.

AUTO_MERGE_APPROVED