[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

• 0b1cf9f ci(merge-pr): move concurrency to job level to avoid cancelling pending runs when skipped
• f09bd4b Merge pull request ci(.github): move concurrency to job level to avoid cancelling pending runs when skipped #76 from legendu-net/push-momwyvnkysun

[dclong]

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

---

Code Review: PR #77 — move concurrency to job level in merge-pr.yaml

• Gather context (PR diff, files changed)
• Understand the request (review PR ci(.github): move concurrency to job level to avoid cancelling pending runs when skipped #77, decide auto-merge safety)
• Review the change
• Post review findings and auto-merge decision

Summary

This PR moves the concurrency block in .github/workflows/merge-pr.yaml from the workflow level down to the merge_pull_request job level (lines 55-63).

Analysis

The reasoning in the added comment is correct and matches documented GitHub Actions concurrency-queueing behavior: cancel-in-progress: false only protects a run that is already in progress. A run that is merely queued/pending in a concurrency group is still superseded (cancelled) whenever a newer run enters the same group — regardless of the cancel-in-progress setting.

With the old workflow-level placement, every triggering event (including workflow_run events whose if: condition would cause the job to be skipped, e.g. a failed/cancelled upstream run) joined the merge-pull-request group as soon as the workflow started, before the job's if: was ever evaluated. That meant a legitimate, already-queued merge run could be bumped out of the queue by a subsequent run that was destined to do nothing.

By moving concurrency onto the job itself, a run whose if: evaluates to false skips the job entirely and never joins the group, so it can no longer cancel another pending merge run. This is a real, narrow bug fix and the change is minimal and self-contained:

• Syntax is valid — job-level concurrency is supported for jobs that call a reusable workflow via uses: + secrets: inherit.
• Indentation/placement under merge_pull_request: is correct and consistent with the job's other keys (if, uses, with, secrets).
• The comment was updated to explain the new placement rather than left stale.
• No other files or logic are touched; blast radius is limited to this one workflow's concurrency handling.

I didn't find any correctness bugs, and there are no other blocking issues (style/cleanup nits are not applicable here — the change is already minimal and well-commented).

AUTO_MERGE_APPROVED