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)

We know Uber has some great internal tooling (there's even a paper published on their merge queue: https://eng.uber.com/research/keeping-master-green-at-scale/). We had various Uber engineers using Mergify on open source repositories those last years. I didn't check recently if that was still the case, I'll make sure our lis is not too much outdated.

I definitely agree with your view on how pipelines can be different. I think none of our customers has something that is exactly the same. However, many of them don't have the workforce to build in house or even to optimize as far as you would do in a (very) large company.

I'd be curious to know what you find limited in off-the-shelf solutions?

(disclaimer: I'm from the Mergify team )

We were using Gerrit and Zuul.

We move to GitHub to have a lower barrier of entry for new contributors.

Fixed, thanks a lot!

Thanks!

It does support all the merging feature that GitHub provides. There are features request already to support even more merge methods. :)

A few months ago, we moved a project to GitHub and missed the automation we used to have on the old platform. For example, we like to merge pull requests automatically when the CI passes and the code has been reviewed and approved.

That's why we started Mergify!

Now, it has a few more features to help automating workflows around pull requests, such as the ability to backport pull request to maintenance branches, delete merged branches, etc.

Feel free to try it out and let us know what you think!