Pull Request Merge Queue Limited Beta

For now, it looks like they are using Gitlab's model where they are speculatively executing items in the merge queue which will push up against max concurrent runner counts (cloud) and run up bills (self-hosted). I hope they add bors-like batching soon.

Unfortunately, I don't see anything in the docs allowing you to detect a merge-queue run compared to a regular run. If they are treated as master pushes, then that has downsides related to deployments that might happen when only part of the pipeline succeeds and the whole thing gets rejected. If they aren't treating it as master pushes, I don't see any way to detect a merge-queue run to allow a two-tier CI system (fast but imprecise for PR iteration, complete run on merge). Something like bors' `try` is also important for a two-tier CI so you can do a full CI run on-demand. I'm sure there are ways around this.

It at least allows jumping the queue but doesn't seem to restrict that, relying on trust among people with merge-access. One feature it lacks compared to mergify is the ability to skip the PR status check run when jumping the queue because it will be redundant with the merge queue run (for expediting major issues).

See also the notes I've been collecting, comparing different merge queues: https://epage.github.io/dev/submit-queue/