[danpalmer]

I think merge trains weren't a feature when I worked with GitLab, it was a while ago. This does certainly solve it, but at the cost of quite a different process. If what you're optimising for is time to release, merge trains add an overhead. At some point that overhead is worth it, but it depends on the team/product/etc.

Having just one runner be the deployer is an option too. I think we used hosted runners so not sure if this is possible in that setup? This would also make pipelines harder to optimise. Often there are many parts in pipelines that are safe to do in parallel, and only a few "critical sections" around which you want locking. This would solve simultaneous releases, but not the general case of the problem (which at least Jenkins and GitHub Actions manage ok).

GitLab always felt to me like Travis++, whereas systems developed later felt like they were built on fundamentally better primitives. Jenkins is a weird one because it has all of the features, can do all of these things, really quite well in many cases, but has a pretty bad developer experience and required a lot of maintenance to run a performant and secure install.