Renovate doesn't upgrade nodejs in Dockerfile if it was already merged in .nvmrc

[prymitive]

What Renovate type are you using?
Renovate GitHub App

Describe the bug

I have a repo that contains React app with .nvmrc file and 2 different Dockerfile files that include nodejs docker image. Renovate created a PR for .nvmrc update but it never created PRs for Dockerfile upgrades.
Note that docker images for nodejs always show up a few days after the release, so I didn't expect those upgrades to happen all at once.
After checking today if nodejs images are ready I was surprised to see that they are there for at least a day, but Renovate didn't create any PRs, which I expected to happen.

Did you see anything helpful in debug logs?
If you are using the Renovate App, log into https://renovatebot.com/dashboard and locate the correct job log for when the problem occurred (e.g. when the PR was created).

I did look at logs and I think the issue is caused by renovate using same branch for all nodejs upgrade (regardless if it's docker or nvmrc). Here are the logs that seems to suggest this:

Renovate correctly identifies that there are updates available for my Dockerfiles:

[...]
"dockerfile": [
      {
        "packageFile": "Dockerfile",
        "manager": "dockerfile",
        "deps": [
          {
            "depName": "node",
            "currentFrom": "node:10.15.1-alpine",
            "currentDepTag": "node:10.15.1-alpine",
            "currentValue": "10.15.1-alpine",
            "datasource": "docker",
            "commitMessageTopic": "Node.js",
            "lineNumber": 0,
            "fromPrefix": "FROM",
            "fromSuffix": "as nodejs-builder",
            "updates": [
              {
                "fromVersion": "10.15.1",
                "toVersion": "10.15.2",
                "newValue": "10.15.2-alpine",
                "newMajor": 10,
                "newMinor": 15,
                "updateType": "minor",
                "isSingleVersion": true,
                "newVersion": "10.15.2"
              },
              {
                "fromVersion": "10.15.1",
                "toVersion": "11.10.1",
                "newValue": "11.10.1-alpine",
                "newMajor": 11,
                "newMinor": 10,
                "updateType": "major",
                "isSingleVersion": true,
                "newVersion": "11.10.1"
              }
            ],
[...]

But later logs show that it decided not to raise the PR for it because there is already merged branch with that name:

DEBUG: Branch has 1 upgrade(s)(dependencies=["node"], branch="renovate/node-10.x")
DEBUG: recreateClosed is false(dependencies=["node"], branch="renovate/node-10.x")
DEBUG: findPr(renovate/node-10.x, chore(deps): update node.js to v10.15.2, !open)(dependencies=["node"], branch="renovate/node-10.x")
DEBUG: Found PR #479(dependencies=["node"], branch="renovate/node-10.x")
DEBUG: Found closed PR with current title(dependencies=["node"], branch="renovate/node-10.x")
[...]
DEBUG: Returning from graphql closed PR list(dependencies=["node"], branch="renovate/node-10.x")
DEBUG: Closed PR already exists. Skipping branch.(dependencies=["node"], branch="renovate/node-10.x")
{
  "prTitle": "chore(deps): update node.js to v10.15.2"
}
INFO: Merged PR is blocking this branch(dependencies=["node"], branch="renovate/node-10.x")
{
  "pr": 479
}

Looking at other log lines I see that other docker PRs are using branch names with docker prefix:

DEBUG: getBranchPr(renovate/docker-prom-alertmanager-0.x)(dependencies=["prom/alertmanager"], branch="renovate/docker-prom-alertmanager-0.x")

Link to debug logs - https://renovatebot.com/dashboard#github/prymitive/karma/49396930

Logs mention recreateClosed option, and I guess that enabling it could potentially be a workaround for this, but the documentation states that recreateClosed shouldn't be needed normally, which seems to confirm that the observed branch collision is likely a buggy behaviour.

To Reproduce
Steps to reproduce the behavior:

1. Create repository with nodejs version managed by .nvmrc
2. Create a Dockerfile that uses official nodejs images
3. Wait for nodejs release

Expected behavior

Renove should upgrade nodejs in both .nvmrc and all Dockerfile files.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

[rarkins]

For now, either:

• Rename the blocking PR, or
• Enable "masterIssue": true in your config and find/check the blocked PR

A solution for next time if possible is to wait until all your Node.js versions have been updated before merging.

Otherwise, this is a challenging problem. It's designed so that you can close a PR to skip a particular version and not have it reopened. But in this case the Docker ones came after you already merged the nvm reference. I'm thinking whether I need to remove the merged blocking and only keep in closed blocking.

[prymitive]

Obviously I’m missing lots of context on the internals of renovate, but wouldn’t it be possible to use a ‘docker’ prefix for branches targeting dockerfile, like with other docker image updates?
Is the name of the branch for nodejs always the same to bundle all updates into a single PR? If so isn’t that the part that’s subject to races due to different timings of releasing binaries and docker images?
I wouldn’t mind having separate PRs for all updates.

[rarkins]

Right now, combining all Node.js updates into a single PR is "a feature, not a bug". The problem is if they don't come close enough together that you start merging already. Our default is to use a docker- prefix in branches but that's removed in Renovate code specifically for Node.js only.

[prymitive]

I've just noticed that for my second Dockerfile there's no update picked up, updates list is empty:

{
        "packageFile": "demo/Dockerfile",
        "manager": "dockerfile",
        "deps": [
          {
            "depName": "node",
            "currentFrom": "node:10.15.1-alpine",
            "currentDepTag": "node:10.15.1-alpine",
            "currentValue": "10.15.1-alpine",
            "datasource": "docker",
            "commitMessageTopic": "Node.js",
            "lineNumber": 0,
            "fromPrefix": "FROM",
            "fromSuffix": "as nodejs-builder",
            "updates": [],
            "warnings": [],
            "sourceUrl": "https://github.com/nodejs/node",
            "dockerRegistry": "https://index.docker.io",
            "releases": []
          },

This might be a separate issue.

[rarkins]

Yes probably a separate issue

[prymitive]

Enabling masterIssue created an issue with list of closed PRs, which is a nice feature on its own, so I'm happy to use that as a workaround for now.
I'll grab some logs and open a separate issue tracking that second Dockerfile. Thanks!

[rarkins]

Thanks very much for your help troubleshooting

[rarkins]

Todo: turn the Node.js grouping into a rule instead of hardcoding it

[edmorley]

Hi!

We had a similar problem with yargs not being updated.

What happened was:

• Renovate opens PR to updateyargs dependency from 12.x to 13.x for a particular monorepo package (we're using Yarn workspaces)
• that PR is merged (Update dependency yargs to v13 (old) neutrinojs/neutrino#1301)
• afterwards someone adds a new monorepo package that has a dependency on yargs 12.x
• Renovate then never updates the 12.x yargs version in that package to 13.x since it sees the already merged PR (eg https://renovatebot.com/dashboard#github/neutrinojs/neutrino/60014119)

I think the solution here is to differentiate between "closed without merging" and "closed since merged", and only skip opening a new PR for the former not the latter.

[rarkins]

The problem was what happens after someone rolls back a bad release that was previously accepted/upgraded.

In such cases, is it acceptable to raise a “duplicate” PR after the rollback that then needs to be Closed without merging in order to disable that version?

And the bigger problem was if that was set to automerge! Renovate would keep automerging the faulty version. But maybe we can try to disable automerge the second time of a previously merged PR was found.

[k2snowman69]

I just ran into this same situation and wanted to propose a counter point to your statement "what happens after someone rolls back a bad release that was previously accepted/upgraded."

Right now what I've been doing whenever I rollback a bad version is update the renovate.json at the root to limit the allowed version to everything below the breaking version. Then once it's fixed I remove the package rule and allow renovate to keep going.

I'm having to currently run with recreateClosed which isn't quite the best solution here.

[rarkins]

I suggest you use masterIssue: true instead. It gives visibility into closed PRs