Merge trains without merge request pipeline
Problem to solve
From: https://gitlab.com/gitlab-org/gitlab-ee/issues/9186#note_150188502
Once a commit is merged from the train to the target branch will CI run again on the commit to the target branch? I suppose the answer is "yes" because the master branch might run a different CI pipeline to the one used for MRs and branches.
In this scenario I am a bit worried about the impact this will have on our CI resources. Each MR will be built three times.
- When the MR is made,
- When it joins the train
- When it is merged.
The second and third runs should run CI on exactly the same commit as each other so are redundant if the pipelines are the same. Running CI on master is essential to make artifacts available though so unless there is some thought given to this in the implementation I fear the merge train will be too costly when CI takes a long time to run (6 hours for us).
Perhaps it would be good to allow more of a batch mode which groups a number of MRs together into a batch and then builds each one individually after they have landed.
Intended users
Developers
Further details
Proposal
It's not the initial case for merge trains, but some users may want queueing of merges into master without the merge request pipeline to validate that things will work. They are more interested in an orderly flow of changes to master than about any particular pipeline breaking master. This issue would introduce the ability to set up merge trains that just merge in sequence, without the merge request pipeline.