main plus every PR ahead of it — so what merges is what was actually tested, even when ten PRs land in the same hour. That predictive testing model is shared across most modern merge queues.
Trunk Merge Queue runs on four mechanics. Predictive testing is the correctness baseline; the other three are how Trunk makes it fast and resilient.
Predictive testing
Test against everything ahead.
Parallel queues
Lanes for unrelated PRs.
Anti-flake protection
CI gets a second chance.
Batching
Test many PRs in one CI run.
When does this make sense?
- Monorepo with lanes of work that don’t overlap → parallel queues
- Flaky tests blocking real merges → anti-flake protection
- 50+ PRs/day, CI bill climbing → batching
- Single-track GitHub Merge Queue choking → all three
More to dial in
Other optimizations worth knowing about:- Priority merging — fast-track urgent PRs (hotfixes, incident response) to the front of the queue without bypassing it
- Predictive testing internals — how the foundational mechanic actually works
- Testing concurrency — how many PRs the queue tests at once
- Direct merge to main — skip retesting when a PR is already up to date with
mainand the queue is empty
Set it up
- Install the Trunk GitHub App (5 minutes)
- Create your first queue (2 minutes)
- Submit a test PR