Config-help: Understanding how to configure "Immortal" PRs

[bjeanes]

Some PRs open as "immortal" but that word does not appear anywhere on the docs site (afaict) or in any issues here.

What are immortal PRs and how is it specified whether something is immortal or not?

[rarkins]

Normally, Renovate uses the branch + PR title as a lookup key to determine if a PR has been raised before. e.g. renovate/webpack-4.x and "Update webpack to v4". So if that PR is raised to a user and the user closes it, it tells Renovate they don't want to see that major update anymore. Renovate "knows" this the next time it runs by checking if the same branch + title already existed and was closed unmerged. If so, then it skips creating it again.

There are times though when this is not appropriate, e.g. for "lock file maintenance" PRs or "pin dependencies" or "update all dependencies" PRs. I've used the word "immortal" to mean "you can't just close it and it goes away". In those cases, you will see it created again because it would be a mistake for us to skip it forever.

[bjeanes]

Hmm, but i got this for updates too. In particular for Apollo and Babel updates. That doesn't fit the criteria you've outlined...

I'm on phone but can add a screenshot shortly when I'm back home

[rarkins]

Sure, please do.

It usually happens with groupings when they have different versions. e.g. if they are all an exact version like v3.1.4 then the PR won't be immortal, because closing it means "ignore v3.1.4". But if the PR was something like "Update babel packages" then if we let you close it and it wasn't immortal then it would mean you just ignored babel forever because all future PRs would also have the title "Update babel packages".

[bjeanes]

Ah well both Apollo and Babel do have groups so I suppose that's true. That heuristic seems insufficient though. In the case of Apollo it was a major version with breaking API changes. It was never something that Renovate would be able to update on its own...

[bjeanes]

I am guessing Renovate is relatively stateless, which is why it looks at existing PRs and their titles to make decisions, so I can see how this would happen given the title doesn't include a version number to disambiguate.

A few things come to mind:

• Clearer description clarifying why something is immortal (or better yet, use this term only for things which are by-design immortal—like pinning)
• Can the PR body be inspected in any meaningful way to figure out which versions were actually ignored?

[rarkins]

You are right re: stateless. 90% of the time it's one of the strengths - it doesn't get "out of sync" with github, it runs in CLI or hosted service, etc. But 10% it can be difficult.

I have been considering whether to embed hidden metadata inside PR bodies using HTML commenting, and then do a compare of the current updates with the last-closed updates. It would mean though that the instant any of the versions are different to what you previously closed, then you'll get the PR created again.

If the apollo ones are all v2 then in theory we should be able to detect that and put v2 in the title to make it non-immortal.

[bjeanes]

You are right re: stateless. 90% of the time it's one of the strengths - it doesn't get "out of sync" with github, it runs in CLI or hosted service, etc. But 10% it can be difficult.

Totally. I think that's brilliant, esp if that 10% can be massaged towards 0% :D

I have been considering whether to embed hidden metadata inside PR bodies using HTML commenting

I wondered about this. It seems like there may be something to that approach...

It would mean though that the instant any of the versions are different to what you previously closed, then you'll get the PR created again.

That seems relatively consistent with existing behaviour, though. That sounds an awful lot better than re-opening constantly!

A nice way to ameliorate that (and a neat feature in its own right!) would be to comment with a snippet of config that the user could add to their config file that would permanently ignore that/those deps (and/or up until a specific version that could be clearly specified in that snippet).

Alternatively, instead of opening new PRs, perhaps you could leave a comment on a previously closed (not merged) PR for that dep saying "there's a new version since you last rejected this upgrade, would you like me to open a new PR for it?". I'm not sure if you could use the checkbox hack you use for rebasing as a way to answer or if there are better options (emoji reaction?)

If the apollo ones are all v2 then in theory we should be able to detect that and put v2 in the title to make it non-immortal.

That was the 3rd thought I had written, but I ended up removing it. That seems like it could be nice in some cases but surprising in others... Then what happens if I do ignore that? Is any V2 ignored forever? What if it is, but then I manually update to 2.x and 2.x+1 is released. Is it still ignored?

[rarkins]

If you ignore a major PR (e.g. update to v2) then Renovate won't suggest v2 again, no matter how many more 2.x releases there are. However if you subsequently update to v2 manually, then Renovate will kick back into action and propose you minor or patch updates in 2.x.

One other feature that can make this nicer is to use the "masterIssue" feature - which I haven't actually documented yet, as I wanted to dogfood it a bit. Check out https://github.com/renovatebot/renovate/issues/2743

You can see there that I've closed (ignored) openpgp v4:

So if I change my mind and want to upgrade to it without doing it manually, I can just select that checkbox and Renovate will do it for me (lock file included, etc).

[bjeanes]

That master issue is a great idea. I've just enabled it and it has already been helpful!