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.

1. When the MR is made,
2. When it joins the train
3. 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.

Permissions and Security

Documentation

What does success look like, and how can we measure that?

What is the type of buyer?

Links / references

added Category:Continuous Delivery devopsrelease [DEPRECATED] ~2975006 labels

changed milestone to %Backlog

mentioned in issue #9186 (closed)

There is some misunderstanding here. We definitely want to make sure MRs pass before they are merged to master but we potentially don't have the CI resources to run both steps 2 and 3 which have identical pipelines and should produce the same result.

added [deprecated] Accepting merge requests label

Thanks for confiming @mpickering. If your goal is just to disable 2, then wouldn't you achieve that by not enabling merge trains? Sorry if I'm being daft here, but that sounds to me like the existing flow we have today.

The existing flow doesn't work for us as "Merge when pipeline succeeds" is incompatible with the "Fast-forward only" merge strategy. This is worked around now by using a merge bot which acts in a similar manner to the proposed merge train.

We don't want to disable 2, as that ensures only good commits reach master, I was musing about the possibility of sharing work between 2 and 3 if they run the same jobs as each other.

We also have teams interested in having the Merge Train feature as a more basic "just queue" MRs instead of having to set up specific pipelines for merge requests.

I guess this request makes more sense for fast-forward strategies, as it would be just an easy way to set up MR dependencies, and just rebasing the code should be enough to verify that the MR is correct by running the whole pipeline.

For other strategies it wouldn't offer any guarantee, as the guarantee it's specifically that pipeline with on: merge_request jobs.

added customer label

An important feature for the premium customer. Internal ZD https://gitlab.zendesk.com/agent/tickets/126054

Setting ~"group::progressive delivery" based on ~"continuous delivery".

Setting ~"group::progressive delivery" based on ~"continuous delivery".

added grouprelease [DEPRECATED] label

added grouprelease [DEPRECATED] label

added Enterprise Edition label

added sectionops label

added to epic &5122

@v_mishra Merge Request Dependencies could easily benefit from this capability for teams that aren't using CI Pipelines - it the capability allowed queueing of Merge Requests that are dependent on other MRs.

Thanks for the tag @poffey21 (this missed our radar because of the wrong labels. Fixed it)

Merge Request Dependencies could easily benefit from this capability for teams that aren't using CI Pipelines - it the capability allowed queueing of Merge Requests that are dependent on other MRs.

This sounds like a really interesting take. cc @jheimbuck_gl I've marked this as workflowproblem validation for now. This issue will increase the scope for merge trains as a feature.

I have a fun prospect that is very interested in leveraging GitLab for MRs & SCM but are leveraging their own CI Platform. They recognize they're a unique use case and might even be interested in contributing to the efforts here, @jheimbuck_gl and @v_mishra.

@poffey21 - we would appreciate hearing more, especially what other approaches they are looking at for this.

@jheimbuck_gl the stacked diffs offering feels relatively similar to I think what the goal would be, where you can bundle merges easily together and then queue them up for merge - but not necessarily dependent upon the Merge Train or even CI Pipelines.

Source: https://graphite.dev/

@poffey21 thanks!

@phikai if there aren't any pipelines involved i'm not sure this matches up to my team but not sure it matches yours either?

@jheimbuck_gl I'm not sure I even understand what this issue and conversely this thread are asking for in terms of features.

We do have an issue for stacked diffs, but it's not anything we're looking at currently.

The relation to merge request dependencies isn't clear to me either because I believe stacked diffs, like other forms of working with atomic commits can be merged in any order with/without the other things also being merged.

I could see an enhacement to merge request dependencies that does allow you to queue automatically merge all the MRs if they all meet requirements (which is maybe the ask here?), but I'd have to think about that more.

@poffey21 does that sound right?

I could see an enhacement to merge request dependencies that does allow you to queue automatically merge all the MRs if they all meet requirements (which is maybe the ask here?)

@jheimbuck_gl and @phikai an enhacement to merge request dependencies that does allow you to queue automatically merge all the MRs was exactly what I was thinking. The reason I was including it here is that it feels like a UI for stacked MRs (be it merge trains or dependent MRs) might actually be able to solve many of these problems at the same time and get us closer to the Stacked Diffs construct #24528.

@phikai does this clarify for you who's best to tackle this work? I'm not certain without running a pipeline it belongs in grouppipeline execution ;)

@jheimbuck_gl It sounds like what @poffey21 is asking for should be a new issue about queuing merge request dependencies. I'm not sure that's what this issue is describing as this issue seems to be talking about batching up CI related things.

@phikai agreed. @poffey21 - could you create a new issue for your feature request? Thanks!

@jheimbuck_gl and @phikai I've created an issue and written down my thoughts.

#369152

I'd love your feedback here.

thanks @poffey21 - I left a comment on the issue.

added grouppipeline execution label and removed grouprelease [DEPRECATED] label

added Category:Continuous Integration devopsverify labels and removed devopsrelease [DEPRECATED] label

added Category:Merge Trains label

removed Category:Continuous Delivery label

removed Category:Continuous Integration label

added workflowproblem validation label

marked #362401 as a duplicate of this issue

marked this issue as related to #362401

mentioned in issue #362401

marked this issue as related to #369152

marked this issue as related to #24528

marked this issue as related to #19238

marked this issue as related to #20691

marked this issue as related to #223113 (closed)

added GitLab Premium label

marked this issue as related to #409670

@hfyngvason @rutshah this issue sounds the same as #415838 (comment 1734817854)

Can you confirm if we can close this out in favour of the new issue with higher participation and activity?

@veethika I think it's somewhat related (due to their CI usage concern), but not exactly a duplicate of #415838. I do, however, think this issue should be closed because it's not entirely clear what the actual problem to solve is or how the proposals would help.

Here, it sounds like the proposal is to allow merge trains but skip the actual merge train pipeline. Which doesn't make much sense to me. Why use merge trains then? And it's already possible to do this using rules to filter out undesired jobs with something like if: $CI_MERGE_REQUEST_EVENT_TYPE != 'merge_train'. I would, however, suggest doing the opposite: Run a predictive test suite in merge requests (tune the completeness of this to minimize merge train flakiness / time to merge), run a full test suite in merge trains, and only a minimal set of jobs on the stable branches (release artifacts etc), with the exception that a full test suite should run for merges that have bypassed the train. All of this is already possible today.

Skipping the merge train pipeline also wouldn't help with the use case stated within the "Proposal" section:

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.

Merges are always sequential, regardless of whether merge trains are used. That's just how git works. And specific merge ordering can be enforced using dependencies. Again, no merge trains required. It sounds like maybe they also want stacked merge request workflows, which are currently a focus of investigation.

I would, however, suggest doing the opposite: Run a predictive test suite in merge requests (tune the completeness of this to minimize merge train flakiness / time to merge), run a full test suite in merge trains, and only a minimal set of jobs on the stable branches (release artifacts etc), with the exception that a full test suite should run for merges that have bypassed the train. All of this is already possible today.

Skipping the merge train pipeline also wouldn't help with the use case stated within the "Proposal" section:

Thanks @hordur

Looking at the conversation in the thread above #10397 (comment 972991730) it does seem like there are mostly inferences going in terms of what's expected here. As a team we have a much better understanding of the feature today and also a clear vision. The epic &12024 has a clear vision and we don't know how this issue fits into it.

cc @rutshah @phikai please reopen if you see the need to.

closed

removed from epic &5122

added sectionci label and removed sectionops label