Bug: assignees and reviewers are reapplied to automerge PRs with failed status checks

[buchstabensalat]

What would you like Renovate to be able to do?
We are using a self-hosted version of renovate on self-hosted gitlab instances (both CE and EE).
We have a general dispatching user to which new Merge-Requests are assigned.
The dispatching user now decides if the merge request will be merged directly or assigns it to another user if he is not able to decide if this is going to break stuff.
The second user has then the responsibility to check this MR in detail.

Our renovate bot runs every hour and every time it runs, it re-assigns the MR back to the dispatching user, which is quite annoying

Describe the solution you'd like
It would be great if there would be a config option to tell renovate to only assign a MR once upon creation.

Additional context

[rarkins]

I'm really surprised that's happening. Can you capture the logs at debug level during one run when Renovate reassigns the user? Renovate normally shouldn't update an MR at all unless it thinks title or body needs to change, and then I wouldn't expect it to update the reviewers.

[testorangemac]

We experience the same issue. Here is our debug log.

Please let us know if you need any further information.

[rarkins]

What line(s) of the log are applicable? Eg where is the assignment and unassignment happening?

[testorangemac]

This is only the part of the log where @types/node is processed. From line 65 a new assignee is added (again) but it seems like it doesn't log that there was already an assignee at the time of processing.

Log

[rarkins]

We do not add assignees and reviewers on MR creation if the MR is configured for automerge.

If status checks fail (preventing automerge) then this logic adds them:

renovate/lib/workers/pr/index.ts

Lines 231 to 237 in e327fa9

	if (
	config.automerge &&
	['failure', 'error', 'failed'].includes(await getBranchStatus())
	) {
	logger.debug(`Setting assignees and reviewers as status checks failed`);
	await addAssigneesReviewers(config, existingPr);
	}

This means assignees and reviewers will continue to be added. I think if you add prCreation="not-pending" to your config then this might work around the issue because then assignees and reviewers will be added at MR creation time. It shouldn't hurt to add it even if it isn't effective as a workaround.

[rarkins]

A better fix would be if we check for existing assignees and reviewers before applying the in this function:

renovate/lib/workers/pr/index.ts

Line 12 in e327fa9

async function addAssigneesReviewers(config, pr: Pr): Promise<void> {

If any exist, then we shouldn't add them.

[testorangemac]

I forgot to add that our situation seems a little different. We simply let the renovate bot do its thing hourly, let it automatically merge when our pipeline succeeds and only want people to be assigned in case the pipeline fails.

The problem being that as soon as a merge request fails that it assigns someone but keeps re-assigning people hourly afterwards. I think prCreation="not-pending" would not serve as a workaround in this case? Since every hour after creation it will still re-assign people?

[rarkins]

If we do a check for any existing assignees/reviewers then that should solve both problems, i.e.

• We won't keep re-assigning the same over and over
• We won't unassign/assign if you manually make changes

Essentially: if automerge is enabled, and tests fail, then only add assignees and reviewers if none already exist.

The only edge case this won't cover is if you want to fully remove assignees/reviewers, because in such a case Renovate will keep adding them again.

[rarkins]

I'm not sure the proposed solution is perfect because it would prevent the following from working:

• Platform already has some form of automated assignees (via CODEOWNERS or another bot)
• Renovate users wish to assign someone else

[njibhu]

I am encountering the same issue. I was actually expecting the behavior to be:

• Renovate will assign the reviewers only when it creates the PR following its configuration, and not touch reviewers anymore until the PR is merged.

And if I want to change the reviewers afterwards myself, renovate won't try to interfere with it
This would play nicely with branch protection rules, and even if there are CODEOWNERS that are not setup as reviewers in renovate, then the git platform would automatically add them (That's how github works, and I think gitlab as well)

[rarkins]

@njibhu sounds like you're expecting https://docs.renovatebot.com/configuration-options/#assignautomerge to default to true?

For that scenario we could definitely skip assigning once tests fail.

[njibhu]

I missed that configuration setting while reading the doc!
Then ignore my comment above
Thanks @rarkins

[rarkins]

@njibhu I think it will only fully solve your problem once #14065 is merged

[hasanwhitesource]

This is fixed.
I had renovate create a merge request and to assign it to a user on a Gitlab repo then I changed the assignee and ran renovate again. It did not reassign the merge request back to the original user after the change.
Also I had the pipeline fail for the test.