Support GitLab "merge trains"

[rarkins]

What would you like Renovate to be able to do?

Support GitLab's "merge train" concept for dependencies, if it's feasible.

Describe the solution you'd like

Ideally Renovate MRs could be layered on top of each other to reduce the amount of rebasing required after each merge.

Describe alternatives you've considered

Today, rebasing can be an O(n) task.

Additional context

https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/
https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-trains/

[rarkins]

@leipert do you have any experience using merge trains to judge if this is feasible or not?

[secustor]

Gitlab doesn't have ATM a REST API for that. https://gitlab.com/gitlab-org/gitlab/-/issues/32665
But it is already implemented in the GraphQL API ( https://docs.gitlab.com/ee/api/graphql/reference/index.html#mergerequest & https://docs.gitlab.com/ee/api/graphql/reference/index.html#mergestrategyenum )

[secustor]

Looks like even while the issue above is still unresolved, there is now a new endpoint which allows to add merge requests to merge trains.
https://docs.gitlab.com/ee/api/merge_trains/#add-a-merge-request-to-a-merge-train

[mschoettle]

It is now possible to add MRs to a merge train without rebasing first. We have been using this for a few months since it became available for fast forward merges.

Or is this issue about Renovate's auto merge feature?

[secustor]

This feature is about using platformAutomerge with merge trains

[secustor]

See the Code of Conduct, updates would have been shared here.