The rule's settings trade CI cost against throughput. merge-queue.json above held these values:
| Setting (API parameter) | Value | What it controls |
|---|---|---|
| Merge method (merge_method) | SQUASH | How queued pull requests land on main |
| Build concurrency (max_entries_to_build) | 5 | Queue branches tested at once (1-100) |
| Minimum group size (min_entries_to_merge) | 1 | Pull requests to wait for before merging |
| Maximum group size (max_entries_to_merge) | 5 | Pull requests merged together (1-100) |
| Wait for minimum group (min_entries_to_merge_wait_minutes) | 5 | Minutes to wait before merging a smaller group |
| Status check timeout (check_response_timeout_minutes) | 60 | Minutes before a silent check counts as failed |
| Only merge non-failing pull requests (grouping_strategy) | ALLGREEN | Every entry must pass, not just the last |
Higher concurrency drains the queue faster at the price of runner minutes, and an early failure discards the builds behind it. Larger groups merge several pull requests in one push, for busy repositories. HEADGREEN (the option unchecked) accepts an entry that failed alone if its group's last build passes: kinder to flaky tests, harder to bisect. Set the timeout just above your slowest required job.