Setup
Five minutes, three changes on your side. Queue to Main is not open for installs yet; this is how it will work.
1. Install the App
Install the GitHub App on your organization and pick the repositories it may use. It asks for: Contents read & write, Pull requests read & write, Checks read & write, Commit statuses read, Metadata read (why each one). The App does not change branch protection.
Keep your branch protection as it is: required reviews and required status checks are what Queue to Main checks before queueing and before merging.
2. Run CI on the test branches
For each queued PR, the App creates a branch fmq/<base>/<pr>, for example fmq/main/214: the latest base branch with the PR merged in. Your CI must run on pushes to those branches. For GitHub Actions, add fmq/** to the push trigger of every workflow that produces a required check:
on:
pull_request:
push:
branches:
- main
- "fmq/**"
Other CI systems: build pushes to branches matching fmq/*, and report results as check runs or commit statuses on the pushed commit.
Each queued PR runs your CI once more, on the test branch, and again if the base moves and the branch is rebuilt. Those minutes are on your CI bill.
3. Queue and unqueue a PR
- Queue: add the label
queueto the PR, or comment/queue. Create the label in the repository if it doesn’t exist yet (any colour). - The PR must be approved and its required checks green. If not, the App removes the label and comments what is missing.
- Unqueue: remove the label, or comment
/unqueue. Closing the PR also removes it. A new “changes requested” review or a dismissed approval takes it out of the queue too.
4. How a merge happens
There is one lane per repository and base branch. The first PR in the lane is tested; the others wait.
- The App builds
fmq/<base>/<pr>from the current base plus the PR (GitHub’s merges API; GitHub does the merge, the App never downloads files). - Your CI runs on that branch.
- When the required checks pass, the App reads the base branch again. If it hasn’t moved, the App merges the PR with a merge commit (or squash, then rebase, if merge commits are disabled in the repository) and deletes the test branch.
- The next PR in the lane starts.
5. Red checks, timeouts and a moving base
- Red: a required check fails on the test branch. The App removes the
queuelabel, comments with the failing check, deletes the test branch and starts the next PR. - Merge conflict: the PR doesn’t merge cleanly onto the latest base. Same as red, with the reason in the comment.
- Timeout: CI hasn’t started on the test branch within 30 minutes. The PR is dropped with a comment; usually
fmq/**is missing from the workflow triggers (step 2). - Base moved: someone merged into the base while the PR was being tested. The App rebuilds the test branch and tests again, up to 5 times, then drops the PR with a comment.
- App down: nothing is merged by the App until it is back. Nothing is blocked: you can merge by hand as usual. There is no uptime guarantee.
6. Where to see the queue
Each queued PR gets a check run (shown as “Queue to Main”) with its position, for example “position 2 of 3”. Its details link to a page listing the whole queue for that installation; the link is signed, so only people with the link can open it.
7. Trial and billing
14-day free trial from install. After that: $49/month per GitHub organization, up to 25 active contributors, monthly, cancel in two clicks in the Stripe customer portal. Without a subscription after the trial, new PRs are not queued (the App comments why). Normal merging is never blocked.
8. Uninstall
- Cancel the subscription in the Stripe customer portal, if you have one.
- On GitHub: your organization’s Settings → GitHub Apps (under Integrations), then Configure next to the App and Uninstall.
- Optionally delete leftover
fmq/…branches and thequeuelabel, and removefmq/**from your workflow triggers.
Uninstalling stops all access at once. To have the data we hold about your installation deleted, see the privacy policy or write to [email protected].