same dependency in multiple locations, only updated once

[djmitche]

Which Renovate are you using?

WhiteSource Renovate App

Other (please write below)

Which platform are you using?

GitHub.com

What would you like to do?

The https://github.com/taskcluster/taskcluster repo has several (ok, many) package.json files. It seems that renovate will sometimes upgrade a package in one of those files, then spot that dependency in another file but decide not to file a new PR because it finds one already. https://github.com/taskcluster/taskcluster/pull/3506 was an example of such -- that upgraded ajv in workers/docker-worker/yarn.lock, but:

clients/client-web/yarn.lock:ajv@^6.1.0, ajv@^6.10.0, ajv@^6.10.2:
clients/client-web/yarn.lock-  version "6.10.2"
--
ui/yarn.lock:ajv@^6.1.0, ajv@^6.10.0, ajv@^6.10.2:
ui/yarn.lock-  version "6.11.0"
--
ui/yarn.lock:ajv@^6.12.0:
ui/yarn.lock-  version "6.12.0"
--
workers/docker-worker/yarn.lock:ajv@^6.10.2, ajv@^6.12.3:
workers/docker-worker/yarn.lock-  version "6.12.5"
--
yarn.lock:ajv@^6.10.0, ajv@^6.10.2, ajv@^6.12.3:
yarn.lock-  version "6.12.4"

I noticed in one of the logfiles that it found this upgrade but saw the merged PR linked above and decided not to make a new PR with the same title (despite the upgrade being to a different yarn.lock/package.json).

I'm not sure if this is just a bug or if there's some config we could adjust to fix this. It does explain the common "huh, I wonder why renovate didn't update that" questions in our slack channel!

[rarkins]

If a dependency is present in multiple files, all files should all be upgraded in the same PR (unless you configure it differently.. which is possible).

Then e.g. if you merge a dependency PR from version v1 to v2, but then later add the same dependency to a different or new file and it also needs an update to v2, Renovate won't create it. This is because it can see that you already updated the dependency to v2 before and does not want to keep trying in case it was a release you rolled back. The "limitation" of this is that it doesn't know if the list of files has changed.

You should see the update showing up in logs, and then you should see the branch being "blocked" by an existing PR also noted in the logs with "Merged PR is blocking this branch".

If you enable dependencyDashboard then you should also get some visibility there as the PR will show up as "Closed/Ignored".

[djmitche]

Thanks -- that might give more visibility in general!

[rarkins]

@djmitche did the dashboard give any visibility into the particular dependency you were concerned about, or had you already resolved that one through other means?

[djmitche]

It didn't appear at first, but it's in there now.

[rarkins]

I saw there was a massive number of pending updates. Was that expected?

[djmitche]

It's due to #911 -- nothing's getting scheduled unless I check the box in the dashboard.

[djmitche]

But, I did get an ajv update and it is now merged, so that's cool! Maybe this should be closed and #911 re-opened.

[rarkins]

I don't think that's an issue now:

I was more just wondering if you had expected to see so many out of date.

The schedule:daily preset you use is 0-2am which is a pretty narrow window and it seems some days it can be missed if there's a lot of npm updates to process. I've added a manual priority bump to the taskcluster org so that it should always get run 1-2 times per window, in which case you should hopefully see the maximum 9 concurrent PRs limit reached by 2am UTC each day until you eventually process them all.

[djmitche]

Thanks! Is that to do with number of runs that occur during that window, or the duration of a run (so, a run starts at 01:00 but takes greater than an hour)?

[rarkins]

A little of both. The schedule is evaluated dynamically per-branch.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed soon if no further activity occurs.