Explain the internal working of GitLab merge trains?

A merge train solves a specific problem: when several merge requests are approved around the same time and merged one after another, each one was only tested against the target branch as it existed before the others merged. Two individually-passing MRs can still break the target branch once combined.

Instead of testing each MR against the current main in isolation, GitLab builds a temporary, cumulative "virtual" branch for each position in the train: the first MR is tested against main, the second is tested against main plus the first MR's changes, and so on down the queue. Only if that virtual pipeline passes does the MR actually get merged into the real target branch, in order.

If a pipeline for an MR in the middle of the train fails, that MR is dropped, and every MR behind it in the queue is automatically re-tested against the corrected sequence, rather than merging on top of a change that never actually landed. This keeps main guaranteed-green even under a high rate of concurrent merges, which plain sequential merging can't promise.