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

Created on 10 Oct 2019  路  8Comments  路  Source: renovatebot/renovate

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
renovate_assign

priority-3-normal bug

Most helpful comment

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.

All 8 comments

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.

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

Please let us know if you need any further information.

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

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

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: https://github.com/renovatebot/renovate/blob/e327fa9af6cf97fdd033efa83519bf4e3291a523/lib/workers/pr/index.ts#L231-L237

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.

A better fix would be if we check for existing assignees and reviewers before applying the in this function: https://github.com/renovatebot/renovate/blob/e327fa9af6cf97fdd033efa83519bf4e3291a523/lib/workers/pr/index.ts#L12

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

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?

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Flydiverny picture Flydiverny  路  4Comments

ChristianMurphy picture ChristianMurphy  路  4Comments

jycouet picture jycouet  路  4Comments

amilajack picture amilajack  路  3Comments

hutson picture hutson  路  3Comments