[david_allison]

It automates the post-approval coordination stages of a PR for maintainers.

Let's say you're an open source maintainer with 3 pending Pull Requests to merge: [1, 2, 3]. Each of which is based off `main`, has passed CI and has been approved.

If you merge all 3 at the same time, there is a chance to break the build: Your CI is testing `main <- 2`, but you're merging `main <- 1 <- 2`. A common example would be when (1) is a user-supplied change, and (2) is a dependency/localisation change, which don't cause merge conflicts but they do break the build/tests.

To do this safely, you need to re-run CI on (2) after merging (1), which is currently a manual process: you need to know that (2) is next to be merged, then rebase/pull + rerun CI for (2).

(There used to be a manual step of 'merge once CI is passed' here, GitHub has recently improved this workflow to allow automation)

Merge queues fully automate the safe approach: it merges (1), runs CI on (2) which fails, then runs CI on (3), which passes and gets merged.

[dvlsg]

What happens if someone wants to merge when the queue is already running CI? Does it interrupt CI and start over, or does it run CI to the end and then kick CI off again with every new merge added to the queue since the last CI kickoff? Or does it merge on a successful CI and put together a new queue with those new waiting merges right after?

[jrochkind1]

Thanks! Github should hire you to write these posts.