Enabling a Merge Queue

A required check proves a pull request works with the main it was tested on, not the main it lands on. Two pull requests can each pass alone and break main together; the strict "up to date" option prevents that, at the cost of a rebase and a CI run per pull request, one at a time. A merge queue (generally available since July

1. automates the wait. Merge when ready adds a pull request to the

queue; GitHub 29 creates a temporary branch under gh-readonly-queue/main/ holding main plus every pull request ahead of it plus this one, runs the required checks there, and merges only if they pass. A failing entry is removed and the entries behind it are rebuilt without it.

Merge queues exist only for repositories owned by an organization: any public one, or private ones on GitHub Enterprise 29 Cloud. BookNest lives on a personal account, and the API refuses the rule:

gh api repos/{owner}/{repo}/rulesets --input merge-queue.json

{"message":"Validation Failed","errors":["Invalid rule 'merge_queue': "],...,"status":"422"}
gh: Validation Failed (HTTP 422)

In an organization (not run here), add the Require merge queue rule to the ruleset with the required checks. Every workflow reporting a required check must also run for the queue, or the queue waits until it times out:

on:
  pull_request:
  merge_group:

Other CI systems trigger on pushes to branches starting with gh-readonly-queue/main/.