Merge trains can sometimes kick an MR out when a previous MR broke the build
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
I have a project with a nontrivial pipeline, where how long the jobs run can vary a lot between invocations. Recently, we had an interesting case that went like this:
Three MRs are added to the merge train: MR A, MR B and MR C.
- MR A renamed a function
- MR B used the old function name, breaking the pipeline.
- MR C had some unrelated change that was fine to merge.
Logically, the result should be that A gets merged, B gets kicked out of the train, C gets rebased on top of A and finally gets merged.
However, it looks like gitlab is a bit overeager in kicking pipelines out of the train. In my case, MR C finished its pipeline first. As such, instead of having its pipeline canceled and rebased on top of A, it got kicked out of the merge train. Then a few minutes later, MR B also failed, and was kicked as well (as expected).
This is very annoying, as it leads to having to "babysit" your merge requests after merging, which is a huge drain on time. And it's especially punishing, as merge trains are considered the "Latest Pipeline" and are not retriable. As such, if "Pipelines Must Succeed" is set, the only solution here is to restart an entire MR Pipeline, so the MR goes back to green, before adding the MR to the merge train again.
In my opinion, an MR should only be kicked from the train only once all the previous pipelines were completed, if they were all green. Otherwise it should be re-added to the (new) merge train. This would prevent this kind of accidental kicking.