Multiple Renovate users

[mfoo]

How are you running Renovate?

Self-hosted Renovate

If you're self-hosting Renovate, tell us which platform (GitHub, GitLab, etc) and which version of Renovate.

GitLab

Please tell us more about your question or problem

Hi all,

My organisation enforces in GitLab that a user may not approve and merge their own changes, which prevents Renovate from auto-merging its own MRs. We can add an exception in our policies to allow Renovate to auto-merge but we've hit a technical problem. This enforcement setting is per repository and you can't override it per user meaning we can't turn the setting off for our Renovate user without turning it off for all users in the repository.

I am considering the option of running two instances of Renovate, each with a different API token. We would kick them off in an alternating fashion, never overlapping, such that it doesn't really matter which one raises the MR and which one approves+merges it.

Is there any reason why this might not work? E.g. detecting commits from the current user? Are there better options?

Thanks!

Logs (if relevant)

No response

[gaeljw]

Pretty sure it won't work: second user/token will see a branch/MR already exists from 1st user/token and will refuse to act on it. At least that's the default behaviour. I've observed that when changing tokens instead of renewing them properly.

[rarkins]

I think this would be a very "heavy" way to achieve what you want, leading to race conditions, edge cases, etc. Better would be for Renovate to introduce the concept of a built-in "approver" (or two) for its own PRs/MRs.

[mfoo]

Thanks all.

I think the simplest option in the short term might be to run a scheduled pipeline using a secondary "Renovate Approver" token that iterates over the API, finds any project where Renovate is enabled, and approves any MR that is raised by Renovate. That way Renovate can raise MRs with automerge using platformAutomerge, and assuming CI passes, the actual merge will be done by GitLab as soon as the second bot hits the approve button. That way I can still use Renovate's logic about whether or not to automerge rather than having to replicate it, and MRs that aren't configured to be automerged still require a human to click the merge button even if the bot accepts them. It unfortunately means that I can't use "automergeType": "branch" and all bumps will require MRs, meaning users will get some email spam.

[rarkins]

Don't your approval policies mean that branch automerge is impossible in the first place? Ie there's no feature we could write in renovate which would overcome a branch protection rule requiring approvals?