[swicken]

Summary

Adds a workflow-level concurrency group to .github/workflows/cicd_2-merge-queue.yml so that a merge group's run is cancelled when the queue re-forms that PR's group.

concurrency:
  group: mq-${{ toJSON(github.event.merge_group.head_commit.message) }}
  cancel-in-progress: true

Closes #38143

Mechanism

When the queue re-forms a group (an entry ahead is ejected or added), GitHub creates a new group with a new head sha and deletes the old gh-readonly-queue/main/pr-<N>-<sha> branch, but it does not cancel the old group's run. That run keeps its whole ~20-job matrix going and holds runners, so the runs for live groups sit in queued behind it.

On 2026-10-21 at 16:13Z, three live groups had three queued runs (39627643636, 39627642388, 39627639204) while three runs for deleted branches (39620380370, 39621293621, 39621297795) were in_progress, the oldest since 14:50. Merges to main that day were 2 against 26 the day before. One ejection (run 39621288435) was a mirror.gcr.io "toomanyrequests: Quota exceeded" image-pull failure, which the extra concurrency plausibly causes.

Workflow-level concurrency evaluates when a run is created, so the older run is cancelled as soon as the newer run for the same key exists, whole run including nested jobs, without waiting for a free runner.

Why the key is the squash message, and why it must be per PR

GitHub expressions have no regex or split, so the PR number cannot be parsed out of head_ref, and head_ref is unique per group so it cannot be the key itself. head_commit.message is the squash message (for example fix(folders): require EDIT on the source folder when moving it (#38113)). Across six runs covering #38113 and #38114 it was byte-identical across re-formations of the same PR and different between PRs, and every message observed was single-line. The embedded (#N) means two PRs cannot collide. The workflow already uses this field in run-name, so the expression resolves.

The key must not be coarser than one PR. The queue deliberately builds several entries in parallel, and a key such as the workflow name or the base branch would cancel live groups and fail the queue (the RWX merge-queue docs warn about exactly this). A per-PR key is safe because a PR has one live group at a time, so a newer run for the same PR proves the older group was destroyed. cicd_1-pr.yml already does the same thing keyed on the PR number.

Why the message is a safe key, and what the key actually depends on

The merge settings on this repository are what make the group name single-line and per-PR unique,
so they are worth stating rather than assuming. From the repository API today:

• allow_squash_merge: false
• allow_merge_commit: true, merge_commit_title: PR_TITLE, merge_commit_message: BLANK

So the generated message is the PR title plus (#N), and the body is never folded in. Every one of
the eight real merge-group runs I sampled across four PRs was a single line of that shape, byte
identical across re-formations of the same PR and different between PRs. The appended (#N) is what
makes a collision between two PRs impossible, which matters because a collision is the one failure
mode that would cancel a live group rather than failing safe.

toJSON(...) is kept as belt and braces. It renders the message as one escaped line, so a multi-line
message could not produce a multi-line group name even if the settings changed. It does not bound the
length, and I could find nothing documented about a limit on a concurrency group name; under current
settings the length is bounded by the PR title, so that question does not arise in practice.

The dependency to watch is therefore the merge settings, not the message. If someone enables
squash merge with squash_merge_commit_message: PR_BODY, group names become long and multi-line with
no code change and no review of this workflow. If a setting ever stopped the number being appended,
two PRs sharing a title would collide. Anyone changing the merge settings on this repository should
look at this block.

No other field in the merge_group payload works as a key. head_ref and head_sha change on every
re-formation, so they would never match and never cancel anything; base_ref is refs/heads/main,
which is coarse enough to cancel live groups; the commit author would cancel across one person's
concurrent PRs. The message is the only field that is stable per PR and distinct between PRs.

First-day watch item: on the first few queue entries after merge, confirm the group name resolves,
that a re-formed group's old run shows as cancelled, and that no live group is cancelled.

What is and is not validated

Not validated by a run. A merge_group workflow can only be exercised through the real queue, so this change is first proven by this PR's own merge queue entry, as #38125 was. I also did not test the concurrency semantics in isolation: a workflow_dispatch workflow is only dispatchable once it exists on the default branch, so a scratch workflow on this branch cannot be run, and I did not push a scratch push-triggered workflow to stand in for it because it would not exercise merge_group anyway.

What was checked: the file parses as YAML and the concurrency mapping is read as intended (Ruby YAML.load_file). actionlint is not installed locally and I did not install it. The evidence for key stability comes from gh api repos/dotCMS/core/actions/runs/<id> payloads, and the concurrency semantics come from GitHub's documentation.

Known limits:

• If a PR title is edited between two formations the key changes and the old run is not cancelled. That fails safe, back to today's behaviour.
• It only fires when a replacement run is created. A PR dequeued entirely with no successor group leaves its run alone. A scheduled reaper workflow that cancels runs whose gh-readonly-queue/* branch no longer exists is the complementary fix for that case, deliberately left to a separate issue.

This PR fixes: #38143

[claude]

Claude finished @wezell's task in 55s —— View job

---

Code Review

I reviewed the diff against origin/main (.github/workflows/cicd_2-merge-queue.yml, +7/-0).

New Issues

• 🟡 Medium: .github/workflows/cicd_2-merge-queue.yml:8-10 — The inline comment describes the key as "The squash message" and warns about "a PR body folded into the squash," but the repository has allow_squash_merge: false with merge_commit_message: BLANK (per your own analysis in the PR body). The field is head_commit.message of a merge commit = PR title + (#N), and a body is never folded in under current settings. Since you explicitly flagged the merge settings as "the dependency to watch," the code comment — the thing a future maintainer actually reads at the point of change — currently points them at the wrong mechanism (squash) and understates the real risk (that a settings change dropping the appended (#N) would let two same-titled PRs collide and cancel a live group). Worth aligning the comment with the PR body's conclusion. Non-blocking.

Assessment of the mechanism (correct)

The core logic is sound and matches the pattern already in cicd_1-pr.yml:35-36 (per-PR concurrency key, cancel-in-progress: true):

• Cancellation direction is right. Workflow-level concurrency cancels the older run when a newer run for the same key is created. The newer run is the live (re-formed) group; the older is the orphan for the destroyed gh-readonly-queue/* branch. So it can only cancel orphans, never the live group — provided the key is per-PR.
• Per-PR uniqueness holds under current settings. head_commit.message is byte-identical across re-formations of one PR (stable key → cancels the orphan) and distinct between PRs via the embedded (#N) (so parallel speculative groups for different PRs never collide). This was verified against real run payloads and confirmed by dotbot.
• Failure modes fail safe. PR title edited mid-queue → key changes → old run not cancelled → today's behavior. PR fully dequeued with no successor → run left alone → today's behavior. Neither can cancel a live group.
• toJSON is correctly defensive — collapses any multi-line value to one escaped line. As you noted in the comments, it doesn't bound length, but under allow_squash_merge: false the length is bounded by the PR title anyway.

The one standing dependency (merge settings, not the message) is well documented in the PR body and the first-day watch items are the right things to confirm.

No bugs, security, or convention issues in the diff. I could not run actionlint (not installed in this environment), but the YAML parses and the concurrency mapping is structurally valid.

Note: I can't modify files under .github/workflows/ (GitHub App permissions don't allow workflow changes), so the Medium above is advisory only — adjust the comment at merge time if you agree it's worth it.

[swicken]

Taken, and the watch item in the description now covers length as well as newlines.

You are right that toJSON solves the wrong half of the problem: it collapses a multi-line squash message to one escaped line, but it does not bound how long that line is, and a PR body folded into the squash makes it long. I could not find a documented limit on a concurrency group name either, so it stays an assumption.

The failure analysis holds up and is worth stating plainly, because it is what makes this non-blocking. Identical truncation is harmless, since the key only has to be byte-identical per PR, not meaningful. Non-deterministic truncation would stop the old run being cancelled, which is exactly today's behaviour, so the change cannot be worse than not making it. Nothing here can cancel a live group, which is the one outcome that would actually hurt.

I have added to the watch item that the first few entries should include a PR with a long multi-line body, and that its group name should be checked for stability across a re-formation. That is the case that would surface it.

Thanks also for the speculative-batching check. Parallel speculative groups having distinct tip commits, so their keys never collide, is the part I had reasoned about but not verified, and it is the thing that would have made a per-PR key dangerous if it were not true.

One correction to the premise this PR was opened on, since it affects how much to expect from it. I originally thought orphaned runs were starving the runner pool. They were not. Checking the job timings afterwards, the live merge-group runs had started within a minute of being created, long before the orphans were cancelled; gh run list reports a run as queued until every job in the matrix has started, which I misread as not started. So this change stops real duplicated compute, and very likely stops the mirror.gcr.io rate-limit ejections that three times the image pulls were causing, but it will not make the queue faster. The queue is slow because each entry's matrix takes 60 to 90 minutes.

[swicken]

Following up on the group-name question: I checked the repository settings rather than leaving it as an assumption, and it closes the multi-line concern.

allow_squash_merge is false on this repository. Merges use a merge commit, with merge_commit_title: PR_TITLE and merge_commit_message: BLANK, so the generated message is the PR title plus (#N) and the body is never folded in. That is why all eight real merge-group runs I sampled were single-line. The length is bounded by the PR title, so the unbounded-length case does not arise under current settings, and toJSON becomes belt and braces rather than the thing holding it together.

The dependency is therefore the merge settings rather than the message, and the PR body now says so. If squash merge were enabled with squash_merge_commit_message: PR_BODY, group names would become long and multi-line with no code change and no review of this workflow. More seriously, if a setting ever stopped the number being appended, two PRs sharing a title would collide, and that is the one failure mode that cancels a live group instead of failing safe. Anyone changing the merge settings should look at this block.

For completeness on why this field and not another: head_ref and head_sha change on every re-formation, so they would never match and never cancel anything. base_ref is refs/heads/main, coarse enough to cancel live groups. The commit author would cancel across one person's concurrent PRs. The message is the only field in the payload that is stable per PR and distinct between PRs.

[wezell]

Hope this is the right... lock key.

[dotCMS-Machine-User]

✅ dotbot review: all reviewer models (meta/muse-spark-1.3, ~z-ai/glm-latest) agree — patch is correct.

_{approved automatically by dotbot}

[github-actions]

dotbot code review:

• Reviewer: meta/muse-spark-1.3 (medium)
• Overall: patch is correct
• New findings this run: 0
• Prior unresolved dotbot findings still relevant: 0
• Active findings total: 0

Workflow-level concurrency keyed on the per-PR merge-group head_commit.message cancels only destroyed-group runs; per-PR uniqueness via embedded (#N) prevents live-group cancellation and failure modes fail safe to current behavior.

Tip: comment with "/dotbot address comments" to attempt automated fixes for unresolved review threads.

_{reviewed by dotbot · meta/muse-spark-1.3 · medium}

[github-actions]

dotbot code review:

• Reviewer: ~z-ai/glm-latest (medium)
• Overall: patch is correct
• New findings this run: 0
• Prior unresolved dotbot findings still relevant: 0
• Active findings total: 0

The change adds a workflow-level concurrency group keyed on the merge-group head commit message, which this workflow already uses in run-name, so the expression resolves. Under this repository's merge settings (PR title with appended (#N)), the key is stable per PR across group re-formations and distinct between PRs, so cancel-in-progress can only cancel runs for destroyed groups; known failure modes fail safe to current behavior. No evidence-backed defects introduced by this patch were found.

Tip: comment with "/dotbot address comments" to attempt automated fixes for unresolved review threads.

_{reviewed by dotbot · ~z-ai/glm-latest · medium}