The merge queue's defining feature is what it builds along the way, not just what it merges. Each candidate gets a branch carrying trunk plus every pull request ahead of it in the line, and the suite runs against that branch, once per candidate [9]. Position four is therefore also a test of one, two and three [10]. The redundancy is structural, so the useful question is which of the earlier candidate runs can be stopped while the last one is still green, and what stopping them costs [16].
The common description says otherwise, and says it with a formula. Asked the situation cold, with no queue mentioned in the question, a current frontier model put the merge queue at the top of its list and described one pre-merge run per batch: roughly 1 + 1/B, about 1.2 at a batch of five [8]. Measured behaviour was 1.76 [9]. The formula only fits that number if B is about 1.3, a fraction far smaller than any real batch size [10]. Nobody on the team had used a merge queue before, and the assistant that proposed it also supplied the projection that made the extra runs invisible [7].
Before adopting 1.76 as your own figure, find where your minutes sit. In their gate, 93% of the time is the test step and every linter together is 30 seconds [2], and 40% of the test step is coverage instrumentation rather than tests [3]. Applied to a 13-to-19-minute run, that is 4.8 to 7.1 minutes of instrumentation, ten to fourteen times the whole lint step [2]. Under it sits a floor of about 226 tests that each start a real process and migrate a real database [4]. Their own warning is the one to keep: a reader with 15,000 fast unit tests has a different problem from a reader with 200 that each stand up a database or wait on a browser grid, and what changes between them is what a single avoided run is worth [15].
At 20 to 30 landings a day, 1.76 runs per landing is 35 to 53 full runs [3]. On the machines they already owned, that is 63 to 95 minutes of test time a day; on the small hosted runner it would have been 6.5 to 14 hours [4]. So the hardware move was the larger win in July, ahead of the redundancy fix [11]. The queue's worst day put about 189 builds through, which prices a build near 53 cents against that day's spend [13][6].
Cancelling the earlier runs is free only when the final candidate passes. Kill positions one through three and a failure at position four tells you the combined state is bad without telling you which change broke it [9]. That is the trade the rest of the work has to price. The whole argument rests on one precondition. If your pull requests never wait behind one another to land, none of this reaches you [14].
