ci: add merge queue trigger support

[alfred-openspec]

Why

Prepared GitHub Actions for Merge Queue so checks run on merge_group synthetic queue commits.

Changes

• Added merge_group trigger on main
• Updated queue-relevant jobs to run for both pull_request and merge_group
• Kept full matrix tests limited to push
• Updated required-check orchestration to match queue behavior

Notes

This is the workflow side only. Branch protection and merge queue settings still need admin setup in repo settings.

Summary by CodeRabbit

• Chores
  • Enhanced continuous integration pipeline to execute comprehensive code validation and testing across additional merge workflows
  • Refined validation check configuration to ensure consistent code quality assurance throughout all deployment paths

[1code-async]

Task completed.

I'll start by reviewing the PR changes. Let me fetch the PR details and the diff.

---

View full conversation

Powered by 1Code

[greptile-apps]

Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.

[coderabbitai]

📝 Walkthrough

Walkthrough

The GitHub Actions CI workflow was enhanced to introduce merge_group event support on the main branch. Job execution conditions were refined to run test_pr and related validation checks on both pull_request and merge_group events, while test_matrix and required-checks-main now execute only on push events.

Changes

Cohort / File(s)	Summary
CI Workflow Event Triggers .github/workflows/ci.yml	Added merge_group trigger and updated job-level conditionals: test_pr now runs on both pull_request and merge_group; test_matrix restricted to push; validation and PR check jobs gated to pull_request/merge_group; main check job gated to push only.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 Our CI runs far and wide,
With merge_group by its side,
Workflows converge, conditions align,
Pre-merge checks that are fine!
Branch protection now divine!

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'ci: add merge queue trigger support' accurately and specifically describes the main change: adding GitHub Actions trigger support for merge queue events (via merge_group).
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch chore/merge-queue-ci

---

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 and usage tips.}

[1code-async]

PR Review: ci: add merge queue trigger support

Overall this is a clean, well-scoped change. The logic for routing events to the right jobs is correct and the conditions are consistent. A few observations:

Looks Good

• Explicit positive conditions — Changing github.event_name != 'pull_request' to github.event_name == 'push' (lines 86, 306) is a good defensive improvement. The old negation would have accidentally matched merge_group, workflow_dispatch, or any future trigger. The explicit == 'push' is clearer and safer.
• Consistent gating — test_pr, validate-changesets, and required-checks-pr are all consistently updated to include merge_group, so the merge queue will see the same required-check topology as a regular PR. That's exactly what's needed.
• Scope — Keeping the full matrix test (test_matrix) limited to push events only is a reasonable choice to avoid burning CI minutes on the queue's synthetic commits.

Potential Issues / Suggestions

1. validate-changesets in merge queue context (.github/workflows/ci.yml:270-274):
   The changeset validation step runs changeset status --since=origin/main. In a merge queue, the GITHUB_REF points to a temporary gh-readonly-queue/main/... ref. origin/main should still resolve correctly as the comparison base, but it's worth verifying this works as expected in practice, since the merge queue commit's history is synthetic and may behave differently with --since. If it causes issues, you could conditionally skip it for merge_group events.

2. changes job (path filter) has no event guard (.github/workflows/ci.yml:21-41):
   The changes detection job using dorny/paths-filter runs on all events (no if: condition). This is fine functionally — the job is lightweight and nix-flake-validate already checks the output — but worth noting that paths-filter behavior may differ slightly for merge_group events depending on how it resolves the base ref. If you see unexpected skips or runs of the Nix validation in the queue, this would be the place to look.

3. Concurrency group may cancel queue runs (.github/workflows/ci.yml:15-17):

   concurrency:
     group: ci-${{ github.ref }}
     cancel-in-progress: true

   Each merge queue entry gets a unique ref (refs/heads/gh-readonly-queue/main/pr-N-<sha>), so concurrent queue entries should not cancel each other. However, if GitHub reuses the same ref for a re-queued PR, cancel-in-progress: true would cancel the prior run. This is likely desirable behavior, but worth confirming it matches your expectations.

4. Both required-checks-pr and required-checks-main share the same name: "All checks passed" (lines 277, 303):
   This is pre-existing, not introduced by this PR. But since merge queue required checks match by job name, having two jobs with the identical name "All checks passed" could cause confusion in the branch protection settings. If the merge queue required check is configured to look for "All checks passed", it might match either job. Consider giving them distinct names (e.g., "All checks passed (PR)" and "All checks passed (push)") to avoid ambiguity — especially important now that merge queue is being added.

Summary

The change is correct and well-structured. The main actionable suggestion is item 4 (disambiguating the required-checks job names), which becomes more important with merge queue enabled. The rest are "watch for" items during initial rollout.

[coderabbitai]

🧹 Nitpick comments (1)

.github/workflows/ci.yml (1)

47-47: Consider disambiguating artifact names for merge_group events.

The test_pr job now runs on both pull_request and merge_group events, but the coverage artifact is always named coverage-report-pr. While the concurrency group (line 16) helps, merge queue events have different github.ref values than PRs, so concurrent runs could potentially overwrite artifacts.

Consider using a dynamic name if artifact traceability matters:

💡 Optional: Use event-aware artifact name

       - name: Upload test coverage
         uses: actions/upload-artifact@v4
         with:
-          name: coverage-report-pr
+          name: coverage-report-${{ github.event_name }}-${{ github.run_id }}
           path: coverage/
           retention-days: 7

Also applies to: 75-80

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/ci.yml at line 47, The artifact name `coverage-report-pr`
used by the test_pr job is ambiguous for merge_group runs and can be
overwritten; update the artifact naming in the test_pr job (and the
upload/download steps referencing the same name around the artifact upload
block) to be event-aware by incorporating a unique identifier such as
github.event_name, github.ref (sanitized), or github.run_id into the artifact
name (e.g., `coverage-report-${{ github.event_name }}-${{ github.run_id }}`) so
merge_group and pull_request artifacts are distinct while keeping the
concurrency group behavior intact.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In @.github/workflows/ci.yml:
- Line 47: The artifact name `coverage-report-pr` used by the test_pr job is
ambiguous for merge_group runs and can be overwritten; update the artifact
naming in the test_pr job (and the upload/download steps referencing the same
name around the artifact upload block) to be event-aware by incorporating a
unique identifier such as github.event_name, github.ref (sanitized), or
github.run_id into the artifact name (e.g., `coverage-report-${{
github.event_name }}-${{ github.run_id }}`) so merge_group and pull_request
artifacts are distinct while keeping the concurrency group behavior intact.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 1833502a-621d-4793-a61d-00f8227ddb57

📥 Commits

Reviewing files that changed from the base of the PR and between afdca0d and f7056ea.

📒 Files selected for processing (1)

• .github/workflows/ci.yml