Add merge_group checks before requiring a GitHub merge queue

A passing pull-request check does not replace the status required for the merge queue’s combined revision.

Source facts

GitHub’s merge queue tests a pull request with the latest target branch and changes already ahead of it. When Actions supplies required checks, workflows must include the merge_group event. That event is separate from pull_request and push. Without the additional trigger, required statuses are not reported for the merge group and the merge fails. Third-party CI has a separate temporary-branch trigger requirement.

Source: GitHub — Managing a merge queue.

Applicability

This concerns merge-queue CI integration. It does not establish that every existing workflow should run privileged deployment actions on a merge-group event.

DSE recommendation

DSE recommends inventorying required status names and the workflows that produce them before enabling the queue. Add the appropriate test trigger and examine assumptions about event payloads and revision identifiers. Keep validation builds separate from release jobs unless the release design explicitly calls for them. Assign someone to diagnose missing statuses rather than repeatedly removing and re-adding the same pull request. Keep the expected status names and merge-group revision in the queue acceptance record. Ask the CI owner to confirm that the additional event runs the intended validation steps, and require a separate release decision before attaching privileged deployment work to that trigger.

Verification

Proposed verification: in an approved test branch, queue a harmless pull request and trace its temporary merge-group revision to the required CI results. Exercise a failing check and inspect the resulting queue decision. Retain the exact revision, trigger and status names so an ordinary pull-request result cannot be mistaken for the combined test.

Official reference

GitHub — Managing a merge queue. Reviewed October 20, 2026.