ci: add merge_group trigger to required-check workflows - #111
Conversation
The merge_queue ruleset (grouping_strategy: ALLGREEN) requires CI Gate, Security Gate Validation, Dependency & Standards Validation, and Check REUSE Compliance, but none of the pull_request workflows that emit these contexts also trigger on merge_group. A queued PR's merge-group build never dispatches these workflows, so the required contexts never report, the entry waits out the 60 minute timeout, and it is ejected UNMERGEABLE. Without this fix the merge queue can never merge anything. - ci.yml: adds merge_group so job 'CI Gate' reports under the merge queue. - security-analysis.yml: adds merge_group so job 'Security Gate Validation' reports under the merge queue. - reuse.yml: adds merge_group so job 'Check REUSE Compliance' reports under the merge queue. - pr-validation.yml: adds merge_group so job 'Dependency & Standards Validation' reports under the merge queue; also guards title-check and body-check to pull_request only (github.event.pull_request.title and .body are null under merge_group), and updates the validation-gate and aggregator scripts to pass on a non-pull_request event instead of treating the now-skipped upstream jobs as failures. The concurrency group falls back to github.ref when github.event.pull_request.number is unset so a merge-group build cannot collide with, or cancel, a PR build's concurrency group. Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Team Run ID: 📒 Files selected for processing (4)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. WalkthroughThe workflows now support GitHub merge-queue events. PR-specific checks skip unavailable metadata, while validation aggregators report skipped checks and allow merge-group runs to pass. ChangesMerge queue CI support
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to Merge-queue builds now run the required CI, security, dependency, and REUSE checks while PR-metadata-only validation is safely skipped for merge-group events. No current merge-readiness risk remains. Suggested labels: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (4 skipped: 4 unsupported.) ✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
🟢 Approval recommended
The merge_group triggers and the pr-validation.yml guards/if: always() setup ensure required check contexts will reliably emit on merge-queue refs without relying on PR-only event fields.
Pull request overview
This PR fixes GitHub merge queue deadlock by ensuring all workflows that emit the ruleset’s required status-check contexts also run on merge_group events, so merge-group refs can report the same required checks as PR refs.
Changes:
- Added
merge_group:triggers to the four workflows that emit the required contexts (CI Gate,Security Gate Validation,Dependency & Standards Validation,Check REUSE Compliance). - Updated
pr-validation.ymlto safely handlemerge_grouppayloads (skip PR title/body jobs when no PR fields exist, and ensure required aggregator jobs still report success). - Adjusted
pr-validation.ymlconcurrency grouping to avoid PR-run and merge-group-run collisions/cancellation.
File summaries
| File | Description |
|---|---|
| .github/workflows/ci.yml | Triggers CI required-check workflow on merge_group so CI Gate reports for merge queue builds. |
| .github/workflows/security-analysis.yml | Triggers security required-check workflow on merge_group so Security Gate Validation reports for merge queue builds. |
| .github/workflows/reuse.yml | Triggers REUSE required-check workflow on merge_group so Check REUSE Compliance reports for merge queue builds. |
| .github/workflows/pr-validation.yml | Triggers on merge_group and ensures Dependency & Standards Validation reports success even when PR-only checks are skipped; fixes concurrency group under merge_group. |
Review details
- Files reviewed: 4/4 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Per-repo review flagged that checking github.event_name and returning success unconditionally would blanket-pass the Dependency & Standards Validation gate under merge_group, regardless of what any real upstream job found. Replace that with a narrower rule: each upstream job's result must be 'success' or 'skipped', evaluated individually. title-check and body-check are the only jobs this gate aggregates today, and they are 'skipped' under merge_group by the pull_request-only guard added in the previous commit (there is no PR title or body to check there); a real 'failure' on either job still fails the gate under both events. This aggregator does not currently wrap any dependency-scan job (needs has always been [title-check, body-check] on main), so no scan result is being bypassed; the comment documents that the same per-job rule must be applied if a real scan job is ever added here. Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Updated: the merge-group gate now accepts success-or-skipped per upstream job (title-check, body-check) instead of a blanket pass on non-pull_request events. A real failure in either check still fails the required Dependency & Standards Validation context under both pull_request and merge_group. This aggregator has never wrapped a real dependency-scan job (needs has always been [title-check, body-check] on main), so no scan result is bypassed by this change. |
Problem
This repo's
merge_queueruleset (grouping_strategy: ALLGREEN,check_response_timeout_minutes: 60) requires four status checks:CI Gate,Security Gate Validation,Dependency & Standards Validation, andCheck REUSE Compliance. None of the fourpull_requestworkflows that emit these contexts also carried amerge_group:trigger.Consequence: a PR entering the queue gets a merge-group build, but that build never dispatches the workflows above, so the required contexts never report. The entry sits at
AWAITING_CHECKS, waits out the 60 minute timeout, and is ejectedUNMERGEABLE. Without this fix, this repo's merge queue can never merge anything, regardless of how green the source PRs are.This is self-healing: GitHub reads workflow files from the merge-group ref, which includes this PR's own commits, so this PR's own merge-group build (once queued) will emit the new contexts.
Workflows changed and why
.github/workflows/ci.yml: addedmerge_group:so jobci-summary(nameCI Gate) runs under the merge queue..github/workflows/security-analysis.yml: addedmerge_group:so jobsecurity-gate-validation(nameSecurity Gate Validation) runs under the merge queue..github/workflows/reuse.yml: addedmerge_group:so jobreuse(nameCheck REUSE Compliance) runs under the merge queue..github/workflows/pr-validation.yml: addedmerge_group:so jobvalidate-dependencies(nameDependency & Standards Validation) runs under the merge queue.No other
pull_requestworkflow in this repo emits one of the four required contexts, so no other file was touched (adding the trigger everywhere would double CI cost for no benefit).Hazards handled
pr-validation.yml'svalidate-dependenciesjob (theDependency & Standards Validationrequired check) depends ontitle-checkandbody-check, both of which readgithub.event.pull_request.title/.body. Those fields are null undermerge_group, so:title-checkandbody-checkare now guarded withif: github.event_name == 'pull_request'and simply do not run in the merge group (there is no PR title/body to validate there).pr-validation-gateandvalidate-dependenciesacceptsuccessorskippedper upstream job (not a blanket event-name bypass on the whole gate). A realfailureontitle-check/body-checkstill fails the gate under either event; only the "skipped by design under merge_group" case is tolerated. This aggregator does not wrap any separate dependency-scan job today (needshas always been[title-check, body-check]onmain), so no scan result is being bypassed; a comment documents that the same per-job rule must be applied if a real scan job is ever added here. Both changes are tagged#CRITICAL/#VERIFYin the workflow comments; please watch the first live merge-group run to confirm the context actually reports green.pr-validation.yml'sconcurrency.groupwaspr-validation-${{ github.event.pull_request.number }}, which evaluates topr-validation-(empty) undermerge_group. Changed topr-validation-${{ github.event.pull_request.number || github.ref }}so a merge-group run gets its own group keyed ongithub.refand cannot collide with, or cancel, a PR run's group (or vice versa). No other touched workflow has a PR-ref-keyed concurrency group.if: github.event_name == 'pull_request'guard on the required-check job itself, so none of the required contexts were at risk of silently skipping in the merge group (the new guards ontitle-check/body-checkabove are additions to protect against null PR fields, not pre-existing guards that needed widening).Verification
actionlinton all four changed files: no new findings beyond the pre-existing repo-wide shellcheck style/info baseline (verified by diffing actionlint output before/after on each file); the two new lines that were flagged for line-length were shortened, and>> $GITHUB_STEP_SUMMARYredirects touched by the rewrite were quoted.pre-commit runon the changed files: all applicable hooks pass (yamllint, no-em-dash, detect-secrets, TruffleHog, etc.).gh api .../rulesetsthat the four contexts above are the complete required-status-check set for this repo's default branch and merge queue; each has exactly one emitting job, and that job now runs on bothpull_requestandmerge_group.Generated with Claude Code