ci: give main a run-unique concurrency group

[devantler]

🤖 Generated by the Agentic Engineer

Why

main can report green on checks that never finished. Every push to main shared one concurrency key with cancellation enabled, so a merge landing while the previous merge's checks were still running evicted them — and a cancelled check is not a failed check, so the commit status settles green regardless.

This repository publishes the plugin marketplace that the agent deployments install from, so an unverified regression on main reaches every consuming runtime.

What

Runs on main each get their own key, so nothing there queues behind or evicts anything else. Pull-request runs are unchanged — superseded ones still cancel.

Part of devantler-tech/monorepo#2690

[devantler]

🤖 Generated by the Agentic Engineer

Requesting review at 0af149f1c4e5. CI settled: 39 passing, 0 failing, mergeStateStatus: CLEAN.

Same change as the merged siblings devantler-tech/kyverno-policies#35 and devantler-tech/platform#2992. The group is keyed on github.run_id for main rather than merely disabling cancellation — a concurrency group holds one running plus one pending run and a third arrival cancels the pending one, so cancel-in-progress: false on a shared github.ref key would still lose a second push's checks while queued.

@coderabbitai review

[coderabbitai]

@devantler I will review the change to the main concurrency group.

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

📝 Walkthrough

Walkthrough

The CI workflow now uses branch-specific concurrency settings. Main-branch runs use unique run IDs and are not cancelled when another run starts. Pull-request runs continue to use ref-based grouping and cancel previous in-progress runs.

Possibly related issues

• devantler-tech/monorepo#2690 — The PR implements branch-specific CI concurrency that preserves main-branch runs while retaining cancellation for pull requests.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly identifies the main CI concurrency change for main runs.
Description check	✅ Passed	The description explains the CI concurrency problem, the proposed fix, and the unchanged pull-request behavior.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[devantler]

🤖 Generated by the Agentic Engineer

Readiness

Programmatically tested. CI settled at 0af149f1c4e5: 39 passing, 0 failing. mergeStateStatus: CLEAN, 0 unresolved threads, 0 non-thread review findings, no conflict with base. Commit signed and verified. actionlint clean on the changed workflow.

Reviewed. Green CodeRabbit at the current head — "No actionable comments were generated in the recent review", naming the reviewed range ending at 0af149f1c4e503af6776c5c9e9106e1d6ddbd4b4; 0 inline comments; commit status success :: Review completed.

Tried and evaluated as a user — with the limit stated. The changed behaviour only manifests on push to main, so there is no pre-merge surface to exercise from a pull request. The same expression form was exercised live on devantler-tech/ksail#6506, where two pushes 73 seconds apart produced cancelled for the superseded run and a live run for the newer one, confirming GitHub evaluates a ref/run-scoped concurrency expression rather than failing the run. The identical change is already merged and behaviourally confirmed on devantler-tech/platform#2992, where the gated workflow ran on the merge commit and completed successfully under the new key.

The default-branch half — two closely-spaced pushes to main both retaining completed checks — is observable only after this lands, and I am not claiming it now.

Promoting on that basis.