Renovate: Use GitLab's built-in automerge

[fgreinacher]

What would you like Renovate to be able to do?

I want Renovate to set the merge_when_pipeline_succeeds flag in GitLab MRs it creates.

Describe the solution you'd like

GitLab supports annotating a Merge Request to be merged automatically when the Pipeline succeeds - this option is also made available via the API. I'd propose that Renovate sets this annotation when automerge is enabled in the config to avoid having to wait for the next Renovatebot run. This is helpful to reduce resource consumption in self-hosted situations where the bot is run on a schedule.

Describe alternatives you've considered

1. Run Renovate on a higher frequency - works, but increases load.

[rarkins]

This sounds like it should work, although I'm not sure just yet exactly where to put the logic. Maybe we could pass the "automerge" value at the time of createPr and then let the GitLab platform logic "accept" the MR immediately after creating it. I'm not sure whether to leave the existing GitLab mergePr function as-is just in case it needs to be called, or turn it into an empty function and rely entirely on GitLab's accepting logic. If someone adds automerge functionality after MRs are created then it could be handy to still have.

A couple of tricky topics to consider:

1. Which GitLab version was this capability added in? We want to support all non-EOL GitLab versions
2. Renovate's automerge capability is nice because it deliberately does not automerge its MRs if the user has edited them. But in this case if Renovate raises a failing MR and then a user edits it, it will automerge as soon as the tests turn green even if the user didn't desire that.

[fgreinacher]

Thanks for the quick feedback! I’ll investigate on the „tricky topics“.

[fgreinacher]

OK, so regarding the topics you mentioned:

1. The last commit to the documentation I linked to was done two years ago, the issue description mentions a target GitLab version of 9.0 (where they introduced API version 4). As Renovate is targeting API version 4, I don't see any compatibility issues here.
2. I agree that this is a nice feature, and merge_when_pipeline_succeeds will only merge when explicitly retrying jobs. When there are any changes to the PR branch _after_ the annotation was set, the merge won't happen automatically (see quote below).

What do you think about making this behavior opt-in via a new automergeType?

Quote from the documentation:

When the jobs are retried and succeed on the second try, the merge request will automatically be merged after all. When the merge request is updated with new commits, the automatic merge is automatically canceled to allow the new changes to be reviewed.

[rarkins]

Thanks for that research. It seems safe to use.

However if it gets disabled after new commits - which would also include the case of Renovate updating/force-pushing its own MR - then it means we probably need additional logic to "accept" existing MRs after branch updates too.

I'm also thinking if we should make this the automatic behaviour for GitLab even if automergeType=pr.

[fgreinacher]

IMO a natural place to handle this situation would be in workers/pr/checkAutoMerge. In there try to defer the merge to the platform when the branch status is 'pending'. So we'd need two new APIs:

1. platform/supportsDeferredMerge
2. platform/mergePr(..., { deferIfNecessary: true })

(Sorry, naming in progress :rofl:)

Update: This idea did not really work out well , see #3308 for a some details and an alternative solution

[renovate-bot]

:tada: This issue has been resolved in version 14.45.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket:

[leipert]

@rarkins Ha, should we re-open this one, as it was reverted with 788215af9947501baab4fb25f3e45decd7ef689e and is dependent on: https://gitlab.com/gitlab-org/gitlab-ce/issues/56698 being fixed?

[fgreinacher]

@rarkins would you take a PR with an opt-in setting to re-enable this feature?

[rarkins]

If you’re aware of the risks ?

[leipert]

Well the underlying bug why it was reverted in the first place still seems to exist: https://gitlab.com/gitlab-org/gitlab/issues/26293

[fgreinacher]

The probability that a MR created by Renovate fails immediately is very low IMO (at least when using more or less the default settings), so yes, I'd probably accept this risk 🤖

I'd definitely prefer a solution in GitLab, but setting up a dev environment for running GitLab sounds like a huge task to me - if now there would be someone working at GitLab in this conversation 🤣

[leipert]

😆 TBH: I would love MWPS (Merge when pipeline succeeds) as well. I may have a look this weekend. We could add a simple guard, like checking if the pipeline already failed and in that case: don't enable MWPS.

Will play around with it for a bit 😄

[fgreinacher]

@rarkins What would be the right place for the new opt-in option (a la gitlabUseMergeWhenPipelineSucceeds)? I think the safest choice would be to expose this as self hosted configuration option, because even when the GitLab bug is fixed Renovate might still run on self-hosted GitLab instances that don't have the fix yet.

[renovate-bot]

:tada: This issue has been resolved in version 19.57.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket:

[ndbroadbent]

@fgreinacher Thanks a lot for working on this! I've just set up Renovate Bot on GitLab (and GitLab CI), and have been trying to get automerge to work for passing builds. (I'm using the hosted service from renovatebot.com.)

Is it correct that the new allowMergeWhenPipelineSucceeds option is only available for self-hosted bots, and it's not available for the hosted service?

Also is it correct that if this option is not available, Renovate Bot will still merge the MRs once the pipeline succeeds? But there might just be a short delay, compared to GitLab's built-in merging?

Thanks a lot for your help!

[fgreinacher]

Is it correct that the new allowMergeWhenPipelineSucceeds option is only available for self-hosted bots, and it's not available for the hosted service?

This was the original idea, but we finally exposed this as "normal" configuration option. We also renamed it to gitLabAutomerge (see https://docs.renovatebot.com/configuration-options/#gitlabautomerge).

Also is it correct that if this option is not available, Renovate Bot will still merge the MRs once the pipeline succeeds? But there might just be a short delay, compared to GitLab's built-in merging?

Yes, that's correct, the new option just speeds the workflow up a bit.