Configurable maximum number of pipelines in a merge train
Proposal
This proposal is to make the maximum number of pipelines that can run in parallel in a merge train configurable.
Currently a merge train has a fixed limit of 20 pipelines [docs]:
Each merge train can run a maximum of twenty pipelines in parallel. If more than twenty merge requests are added to the merge train, the merge requests are queued until a slot in the merge train is free. There is no limit to the number of merge requests that can be queued.
For projects with large pipelines with a lot of stages, this can cause serious contention for resources and is particularly bad in cases where jobs are not interruptible. In these cases merge trains are effectively unusable if you don't have the CI runner capacity to execute 20 pipelines in parallel.
As an example: in our organization our main project with around 35 active developers has a pipeline with 90 jobs and can take approximately 40 minutes to complete. With our runner pool we can generally run 3-4 pipelines in parallel before the number of pending jobs starts increasing significantly).
We had originally built a bot before merge trains was released in order to queue MRs and automatically rebasing and merging them as required, it runs a single pipeline at a time to ensure CI is not saturated, however we would much rather be able to use the built in merge trains feature as it is better integrated into the merge request flow and would reduce our maintenance burden.
In order for us to be able to use merge trains, we'd like to be able to limit the number of parallel pipelines that can be run on a project level. It should be possible to set this as low as 1 (meaning no parallelism) such that each MR in the merge train is merged in sequence.