Batching Strategies (Bors-NG / Tide)

Optimistic merging parallelizes tests but still runs one CI job per PR. For projects with very slow test suites — think 45 minutes to an hour — even parallel jobs are expensive. Batching takes a different approach: instead of testing PRs one at a time, it groups them together and tests the whole group as a single unit.

The "Bus" Method

Tools like Bors-NG (used by the Rust programming language project) and Prow/Tide (used by the Kubernetes project) implement batching. The mechanics:

1. The queue accumulates N approved PRs (e.g., N = 10).
2. It creates a single temporary branch: main + PR1 + PR2 + ... + PR10.
3. It runs the test suite once on this combined branch.
4. Success: All 10 PRs merge to main. You ran 1 CI job instead of 10. 90% cost reduction.
5. Failure: The system doesn't know which PR caused the failure. It performs a binary bisect:
   • Split into two batches: [PR1–PR5] and [PR6–PR10]. Test both.
   • The failing half is split again: [PR1–PR2], [PR3–PR5]. Test both.
   • Continue until the single bad PR is isolated, ejected, and the rest are merged.

In the worst case (one bad PR in a batch of 10), bisection requires log₂(10) ≈ 4 additional CI runs to isolate the culprit. You still save 5 CI runs compared to testing each PR individually.

When to Use Batching vs. Optimistic Merging