ci: trigger the Maven build on merge_group - #249
Conversation
A merge queue builds a candidate on refs/heads/gh-readonly-queue/... and dispatches merge_group, not pull_request. Without this trigger the required 'build / conclusion' check never reports on a queued entry, the entry is ejected after the 60-minute timeout, and nothing can merge into main. Inert until a queue is enabled on this repo; merge_group events are only dispatched by one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014sxAQc2ohWuDz65e2DbVij
|
Important Review skippedAuto reviews are limited based on label configuration. 🚫 Excluded labels (none allowed) (1)
Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository: cuioss/coderabbit/.coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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.
Sorry @OliverWolffGIP, you've used your own review budget of 250,000 diff characters for the last 7 days.
You can request another review in 3 days and 2 hours by commenting @sourcery-ai review. Upgrade to get a review now.
A merge queue does not build the PR ref. It builds a candidate on
refs/heads/gh-readonly-queue/main/...and dispatches themerge_groupevent.Without this trigger, once a queue is enabled:
build / conclusionnever reportsNet effect: nothing can ever merge into
main. So the trigger has to land before the queue is enabled, not with it.This PR is inert on its own — no queue exists on this repo yet, and
merge_groupevents are only dispatched by one. The queue follows fromcuioss-organization'smerge_queue_repos.Verified on
cui-http, which has had the trigger and a live queue since 2026-08-26 — fivemerge_groupruns ongh-readonly-queue/main/pr-*branches, allsuccess. The reusable workflow already handles the event; no change is needed there.Validated locally: