ci: run on merge_group so a merge queue can gate main

[tylerkron]

This must land before the merge queue is enabled. Turning the queue on first would stall every open PR.

Why

A queued PR is tested on a merge_group ref containing main's tip plus everything ahead of it in the queue — the state the commit will actually land in. A pull_request run cannot see that.

That gap is exactly what broke main earlier today. #445 and #444 merged 63 seconds apart, each tested against a main that did not contain the other — #444 on a nine-hour-old check whose base never included #445. Verified after the fact:

commit	contents	result
da35eff	main after #445 only	green (108 tests)
7965b26	main after #445 + #444	red (5 failures)

Neither PR was broken. The combination was. Five later PRs then inherited the breakage and failed for reasons that had nothing to do with their own changes.

The main ruleset already requires up-to-date branches (strict: true), but the daqifi-core team holds bypass_mode: always, so it did not apply. A merge queue closes this properly: it re-tests each entry against the real post-merge state instead of trusting a stale green check.

What changes

• merge_group — required for the queue. Without it the required build check never reports for a merge group, and queued PRs sit until they're timed out of the queue.
• push: [main] — backstop only. The queue makes it largely redundant, but main can still move without passing through a queue (ruleset bypass, admin push), and today showed the cost of an unnoticed red main: CI running only on pull_request left no run on main to point at.

No job or step changes; the required check context stays build.

Queue settings to apply after this merges

Matching the repo's existing config (squash-only, PR_TITLE/BLANK):

• merge method: SQUASH
• grouping: ALLGREEN
• required check: build

🤖 Generated with Claude Code

[qodo-code-review]

PR Summary by Qodo

CI: trigger on merge_group and main pushes to support merge queue gating

⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Add merge_group trigger so merge queue runs report the required "build" check.
• Add push-to-main trigger as a backstop when main moves outside the queue.
• Keep existing jobs/steps unchanged; only workflow triggers are expanded.

Diagram

graph TD
  PR(("pull_request")) --> WF["CI workflow"] --> JOB["build job"] --> CHECK["build check"] --> MQ["Merge queue / ruleset"]
  MG(("merge_group")) --> WF
  PUSH(("push: main")) --> WF

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Only enable merge_group (omit push: main)

• ➕ Reduces CI load from main-only backstop runs
• ➕ Keeps gating entirely focused on merge-queue paths
• ➖ Main can still become red via bypass/admin push without an immediate CI signal on main
• ➖ Harder to diagnose regressions when main moves outside the queue

2. Rely on ruleset strictness / required-up-to-date branches without merge_group

• ➕ No workflow trigger changes required
• ➖ Does not validate the actual merge-queue combined ref; still allows “two PRs green, combined red” situations
• ➖ Can stall or mis-gate merge queue because required checks won’t post on merge_group refs

Recommendation: Keep the current approach: add merge_group so the merge queue can reliably receive the required "build" status, and retain push-to-main as a low-cost safety net for non-queue main updates (bypass/admin pushes). This is the standard GitHub Actions pattern for merge-queue support and avoids stalled queued PRs.

Files changed (1) +14 / -0

Other (1) +14 / -0

ci.ymlTrigger CI on merge_group and push-to-main for merge queue gating +14/-0

Trigger CI on merge_group and push-to-main for merge queue gating

• Extends workflow triggers to include merge_group so required checks are produced for merge queue refs. Adds push on main as a backstop to ensure main gets CI coverage even when updated outside the queue; jobs/steps remain unchanged.

.github/workflows/ci.yml

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}