On 2025-09-02 10:48:46 -0700 (-0700), Russ Allbery wrote: [...]
With merge queues (and presumably also merge trains), the exact MR as it would be merged is separately tested on top of the current target branch and is only merged if those tests pass. You can queue up multiple things for merging and they're each tested one at a time in their merge order and the merge is aborted if the exact state of the target branch after the merge doesn't pass tests, thus avoiding all the cases where automerge can merge an MR into a different state of the target branch than it was tested against.They're the most useful for repositories with a heavy and uncoordinated merge load and help to flush out hidden semantic merge conflicts that aren't obvious to Git.
As long as it's not *so* heavy a load that you have more requests approved to merge than can be tested serially in a reasonable amount of time. In the OpenStack community we developed an optimistically speculative parallelized testing scheduler (Zuul) to address that challenge, since changes were being approved faster than they could be tested and if their final acceptance tests weren't serialized then we could end up merging serious bugs where different changes conflicted functionally.
Side note to the side note, Zuul does support GitLab (as well as Gerrit, GitHub, Pagure...) but is not currently packaged in Debian. The backend bulk of it would be pretty easy to package, it's just a fleet of Python-based services, but packaging the countless JavaScript dependencies for its WebUI would be a gigantic pain.
-- Jeremy Stanley
Attachment:
signature.asc
Description: PGP signature