jd__

FWIW, Mergify's Merge Queue supports this as long as you run it without batching or parallel checks. We expose a config option for semi-linear history while still keeping CI green.

That's super interesting, thanks for sharing the Yelp/PayPal lineage. You're right: there's probably a lot of prior art in internal release engineering systems that never got much written up publicly.

The angle we took in the blog post focused on what was widely documented and accessible to the community (open-source tools like Bors, Homu, Bulldozer, Zuul, etc.), because those left a public footprint that other teams could adopt or build on.

It's a great reminder that many companies were solving the "keep main green" problem in parallel (some with pretty sophisticated tooling), even if it didn't make it into OSS or blog posts at the time.

That's a good point. To clarify, Gerrit itself didn't actually do merge queuing or CI gating. Its model was stacked commits: every change was rebased on top of the current tip of main before landing. That ensured a linear history but didn't solve the "Is the whole pipeline still green when we merge this?" problem.

That's why the OpenStack community built Zuul on top of Gerrit: it added a real gating system that could speculatively test multiple commits in a queue and only merge them if CI passed together. In other words, Zuul was Gerrit's version of a merge queue.

I always expect that the shoemaker's children go barefoot.

Why's that?

Best way is to batch your PRs in a single CI run. That saves CI time and increase your throughput.

It does not seem GitHub merge queue supports this, but some merge queues do support this.

(Julien from Mergify)

Rather 1/5th of Mergify, and still in beta, but that's the spirit yes. :)

(Julien from Mergify)