ci: run CI on merge_group so a merge queue can be enabled - #101
Merged
Conversation
A pull request in a GitHub merge queue is tested on a temporary refs/heads/gh-readonly-queue/... ref, which fires the merge_group event and neither pull_request nor push. Without this trigger the queue would sit waiting on required checks that never start. The concurrency block already behaves correctly for merge groups: they fall through to github.ref, which is unique per queue entry, and cancel-in-progress stays false for anything that is not a pull_request, so a queued run is never cancelled out from under the queue.
Collaborator
✅ Heimdall Review Status
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
danyalprout
approved these changes
Aug 26, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds the
merge_grouptrigger to.github/workflows/ci.yml.Why
A pull request in a GitHub merge queue is not tested on the PR branch. GitHub creates a temporary
refs/heads/gh-readonly-queue/main/pr-N-<sha>ref containing the PR's commits on top of everything ahead of it in the queue, and dispatches themerge_groupevent against it. That ref fires neitherpull_requestnorpush, so as things stand today CI would never start for a queued PR and the queue would sit waiting on required checks indefinitely.This is the prerequisite change: it has to be on
mainbefore the queue is turned on, because the queue's required checks are looked up on the base branch's workflows.Concurrency
No change needed. Merge group runs fall through to
github.ref, which is unique per queue entry, so they never collide with each other or with the PR's own run.cancel-in-progressis already gated ongithub.event_name == 'pull_request', so a queued run is never cancelled — cancelling one would drop its PR out of the queue.Not in this PR
Two follow-up steps are required before the queue actually works, and both are repo settings rather than code:
main's branch protection currently requires onlyHeimdall Review Status. The queue merges when the required checks pass on the merge group ref, soHeimdall Review Statusneeds to either report onmerge_groupevents or be dropped from the required list, and the CI jobs (typecheck,lint,test,docs (generated agent index),public build excludes internal-only surfaces) should be added.main→ Require merge queue, and pick the merge method (the repo is squash-only) plus batch size and timeouts.Testing
actionlint .github/workflows/ci.ymlis clean. The change is trigger-only — no job, step, or permission is modified.