Why MR train merge only first MR

How to Use GitLab Self-managed
,
1

Currently we have an issue with dependabot. to automatically update dependencies in package.json dependabot create automatic MRs per dependency
Let’s assume dependabot created a 3 MRs, I cannot merge them one by one, as after the first one I need to rebase the other 2 and wait for their pipelines to run - which is slow

So I thought MR train can help me, but when I start release train for the first MR and add 2 other MRs (with green pipelines) to MR train,
gitlab launches a few pipelines but really merges only the first MR (which I can merge even without MR train)

Am I doing something wrong or just don’t understand what MR train is?
Is there a way to merge 3 MRs without rebasing other two?

2

I’ve been fighting a similar problem for a couple of months, but until today hadn’t been able to put my finger on exactly what the problem is. Looking at my MRs, they always get pulled out of the Merge Train with a message like:

removed this merge request from the merge train because source branch was updated just now

When I’d looked at this previously, that didn’t make sense, because there was only 1 commit according to the commit tab for the MR. However, I looked a bit closer today and saw that the history indicated that previously the commit reference in the MR was:

99f01bb5 - chore(deps): bump third-party/GDALFramework from 920d765 to 882874f

and immediately following the “removed” message above, there was another commit message indicating:

ae0bafec - chore(deps): bump third-party/GDALFramework from 920d765 to 882874f

I’m taking from this that dependabot saw the source branch change and immediately force-pushed an update to the latest version. Unfortunately, this force push changed the hash for the source branch and caused the MR to drop out of the Merge Train.

Looking at the dependabot configuration, there is a setting for rebase-strategy which determines if open pull requests are rebased when changes are detected. It seems that if this were set to disabled it would solve the problem with Merge Requests. It might also create a problem with existing MRs making them unmergable without manually selecting to rebase using the $dependabot rebase comment (command).

Making the change to my dependabot.yml file to add the rebase-strategy:

version: 2
updates:
  - package-ecosystem: "gitsubmodule"
    directory: "/"
    schedule:
      interval: "daily"
    assignees:
      - "gaige"
    rebase-strategy: "disabled"

Seems to have prevented the auto-rebase from happening, and so far the merge trains seem to now be working as expected.

3

Is there a way to do something similar by hands? Let’s say I created a MR (don’t delete source branch/squash commits) and merged it by accident, so I want to push-force to source branch again and re-merge that MR again. I want to get updated MR as well as Destination branch