3

I'm trialing the "Ultimate" version of GitLab, in particular the Merge Results Pipeline feature, along with the related Merge Trains feature.

I have Merge Results pipeline & Merge Trains enabled for my project, Merge Method is set to Merge Commit, and my .gitlab-ci.yml has the following rules, as per the docs:

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'

This all seems to work nicely, but there's one thing I don't understand.

Imagine there is just one open Merge Request, and there have been no changes on the target branch main since the related branch was created. When I push to the MR branch, I expect a "merge results" pipeline to run, which as I understand it is a preemptive merge of the target branch with my MR branch. The pipeline succeeds, and the MR is now eligible to add to the Merge Train.

And if I do add it to the Merge Train, it builds again and I must wait for this to complete before it can be merged. Why is this necessary? It has already built the result of the merge, and nothing has changed since, and this is detectable, so why the inefficiency?

This leads to my team wanting to use the "Merge Immediately" button instead of adding to the Merge Train, to avoid the superfluous pipeline (and the resulting wait for the actual merge to happen). I don't want this to become a habit since it defeats the purpose of these two features.

Previously we just used FF-only branch pipelines and although it was painful to constantly rebase or merge the target, at least if the build was green and nothing had changed, the merge could happen immediately.

Perhaps I'm missing something with my configuration?

sytech
  • 29,298
  • 3
  • 45
  • 86
davidA
  • 12,528
  • 9
  • 64
  • 96

1 Answers1

-1

This is because the merge result pipeline and merge train are two separate events. GitLab does automatically detect redundant pipelines in merge trains and automatically cancels those redundant pipelines.

However, if you add your MR to a merge train by saying it depends on another MR, what is being built is not the same as the "merged result" pipeline because the refs from the other MRs in the train must be added as well.

Based on your described scenario, the merge train pipeline is not actually redundant and therefore is not automatically cancelled.

It is also worth noting that Fast-forward merge support for merge trains is a planned feature for merge trains to make them more efficient.

sytech
  • 29,298
  • 3
  • 45
  • 86
  • Perhaps I described it poorly - I'm asking about the simplest case where there is only one open MR, targeted at `main`, and it has been built already as a "result" pipeline, and then it is added, unmodified, to a fresh, new Merge Train, as the only MR to be merged, and `main` hasn't changed either, and it builds the exact same thing again. Am I missing something? – davidA Apr 20 '22 at 01:38
  • @davidA did you get answer to this? – sooper May 25 '22 at 17:00
  • @sooper Not really. I took it to GitLab directly (via our allotted Customer Care person) and they weren't really able to give me a proper answer on it. For now we're just living with the double builds. – davidA May 25 '22 at 21:12
  • @davidA this is a shame. We're likely to move to marge-bot because of this – sooper May 26 '22 at 10:17