Add explanation when PRs are autoclosed

[mxey]

What would you like Renovate to be able to do?

On some occasions, Renovate has autoclosed a PR/MR for me, only to create a new MR later (I assume on the next run). I would be useful if Renovate could add a comment to the MR describing why it was autoclosed.

Describe the solution you'd like

When autoclosing a PR/MR, Renovate adds a comment with a reason.

Describe alternatives you've considered

• Manually checking the log files, which might no longer be easily available if the container has since been replaced

[rarkins]

Renovate usually doesn't know the reason for autoclosing, so this is unfortunately not possible without highly complicated guessing in most cases.

Here's how Renovate autocloses:

• During its regular work it determines what branches should be there, and attempts to create them if scheduled and allowed by config
• When it's finished it looks at what other renovate branches are there that shouldn't be, and autocloses them. It doesn't really "know" why they were there, because either config or registries have changed since they were created.

The most common cause of autoclosing is due to change of config. If an earlier config instructed Renovate to create branches A,B,C and then a newer config resulted in branches A and D then what should Renovate say with the B and C it autoclosed? Maybe it's because B and C got grouped into D, or maybe it's something else altogether. Grouping and naming are completely configurable but as a result we can't just "look" at a branch and no for sure why it was there.

Another example would be if a dependency was removed from master or upgraded manually - in that case any existing branches for updating it would be autoclosed. In the case of removal, Renovate now wouldn't even know what that dependency without performing a full parsing/extraction on the branch and attempting to guess that it's a dependency that's no longer there.

If Renovate autocloses an MR and then recreates the same one, that's something I'd like to avoid rather than "document".

For example:

• The autoclose might be because the registry went down temporarily and we thought there's no updates available, so we autoclosed the branch we found that included a previously-found update. The solution to this is: if essential registries cannot be found then we should abort the run. We do this for npmjs.org for example but it's hard to enforce it for others. For example some users have Dockerfiles pointing to a private docker registry and don't care that we fail to look it up. I'm considering in a future major release to default to "abort on registry error" and let users override that behaviour per-host using config.

• The autoclose can happen currently in a scenario like this: You have v1.5.0 in master and a PR for v2.4.0 in a branch like renovate/foo-2.x. Then, v3.0.0 is released so that branch needs to be autoclosed and renovate/foo-3.x is created. The solution here is that we should not put the major version number in the branch name unless the user has configured separateMultiMajor to true. But this might result in lots of reopened PRs for people if we adopt this behaviour as default, so I'm cautious about when/how to do it.

[rarkins]

I'll leave this open, because it's an obvious nice thing to have even if it's pretty hard to do under the hood. And sometimes someone gets a brainwave for how to achieve things like this. But even if we know why a PR was created in the first place, that doesn't mean we can easily guess why it's no longer needed.

[Jamesking56]

Maybe its just worth putting a vague comment to at least remind the user why it could have been closed. Something like:

Renovate has chosen to close this PR, this could be caused by config changes or simply reopening a new PR.

(obviously more fleshed out and better than that)

[rarkins]

@Jamesking56 good idea. Adding a comment explaining common reasons would be a nice start.

[maxdanilov]

Hi, we're experiencing Renovate closing PRs when a registry (quay.io in our case) is down and throws 500s.

Would it be possible to somehow disable the PR closing in this case, or to at least have a debug message in a PR as proposed above?

[rarkins]

You can disable autoclosing here: https://docs.renovatebot.com/configuration-options/#prunestalebranches

I have seen lots of problems with quay.io and would greatly appreciate help from anyone using it. It's hard to know when it's temporarily buggy or permanently broken.

[jsumnerp]

@rarkins if Nuget is down should it abort the run or is this only implemented for npm? Also will the autoclosed prs be recreated in a future run, or will it treat it as if it was closed by the user and ignore that update?

[rarkins]

Nuget is currently not set to abort on failure but you could define a host rule using abortOnError for it: https://docs.renovatebot.com/configuration-options/#abortonerror

Autoclosed PRs are recreated in future runs and not treated as if they are ignored. We rename them - autoclosed in order to achieve that. Also, we have a PR in progress to try to reopen autoclosed PRs if possible instead of recreating, but it's not finished yet.

[kevindigo]

It sounds like PRs might be autoclosed if the branch is no longer needed (which makes sense) OR if a registry is down. I'm new to the renovate landscape, but why would the PR be closed just because a registry happened to be down during that run? If it does close a PR for that reason, it seems like it should say so in a comment. If there's something I can read to understand why this behavior is desired, please point me to it.

We had a bunch of PRs get autoclosed, probably due to a temporary network problem, and it caused a lot of confusion and frustration.

[rarkins]

The challenge is that Renovate doesn't know why a PR is autoclosed - it just knows that there's a branch, and that branch is no longer needed. There's too much logic/configuration which happens between a dependency lookup and a branch being created for Renovate to reliably map them and "know".

For certain public repositories there's a built-in logic to abort a run if a registry lookup fails. You can apply this logic to your own registries using abortOnError

[kevindigo]

Thanks for that clarification. It sounds like abortOnError is what we want.