Renovate keeps trying to refresh our lockfile

[G-Rath]

What Renovate type, platform and version are you using?

I'm using the hosted app on Github.

Describe the bug

Renovate keeps opening "lock file maintenance" PRs, despite having opened ones already on the same day which were successfully merged.

We've had four on our eslint config repo:

• chore(deps): lock file maintenance ackama/eslint-config-ackama#93
• chore(deps): lock file maintenance ackama/eslint-config-ackama#94
• chore(deps): lock file maintenance ackama/eslint-config-ackama#95
• chore(deps): lock file maintenance ackama/eslint-config-ackama#97

The most recent one seems to be in response to me having had to re-generate the lockfile and restore the peer dependency constraint for eslint, which resulted in fsevents being added to the lock - it seems renovate is having issues with optional dependencies.

We also had a double up over at eslint-plugin-jest:

• chore(deps): lock file maintenance jest-community/eslint-plugin-jest#834
• chore(deps): lock file maintenance jest-community/eslint-plugin-jest#835

Twice it seems actually:

• chore(deps): lock file maintenance jest-community/eslint-plugin-jest#827
• chore(deps): lock file maintenance jest-community/eslint-plugin-jest#828

And finally, we seemed to have had renovate open PRs that it shouldn't have: the config we're using for eslint-config-ackama matches what eslint-plugin-jest is using, yet eslint-config-ackama got PRs for individual packages which eslint-plugin-jest did not:

• chore(deps): update dependency @types/jest to ^26.0.20 - autoclosed ackama/eslint-config-ackama#83
• chore(deps): update dependency @types/node to ^14.14.31 - autoclosed ackama/eslint-config-ackama#84
• chore(deps): update dependency eslint to v7.24.0 - autoclosed ackama/eslint-config-ackama#85
• chore(deps): update dependency eslint-plugin-flowtype to ^5.7.1 - autoclosed ackama/eslint-config-ackama#86
• chore(deps): update dependency eslint-plugin-jest to ^24.1.5 - autoclosed ackama/eslint-config-ackama#87
• chore(deps): update dependency eslint-plugin-prettier to v3.4.0 - autoclosed ackama/eslint-config-ackama#88
• chore(deps): update dependency ssri to 6.0.2 [security] - autoclosed ackama/eslint-config-ackama#91
• chore(deps): update dependency eslint to v7.25.0 ackama/eslint-config-ackama#92

I didn't open a bug for this because it only seemed to happen a couple of times and I figured it was caused by #9635 & co, but am mentioning it here as it might be related.

Relevant debug logs

I don't know what logs are actually relevant - looking over them, they all seem to make logical sense on their own; I suspect this is an infrastructure issue.

Happy to provide logs upon request :)

Have you created a minimal reproduction repository?

Please read the minimal reproductions documentation to learn how to make a good minimal reproduction repository.

• I have provided a minimal reproduction repository
• I don't have time for that, but it happens in a public repository I have linked to
• I don't have time for that, and cannot share my private repository
• The nature of this bug means it's impossible to reproduce publicly

Additional context

I suspect that this is more of an infrastructure problem - specifically I'd say that renovate is being run every hour without any check on if its already done a lockfile refresh today.

[rarkins]

Renovate keeps opening "lock file maintenance" PRs, despite having opened ones already on the same day which were successfully merged.

There is no concept that "if you've already opened one today on the same repo then don't open another one", so this particular point is not relevant.

Renovate will by default attempt lock file maintenance according to the schedule before 5am on monday so if it raises a PR early Monday and you merge it, it will try again to see if the lock file needs updating. If you plan to eagerly automerge such PRs then you could consider lowering the default schedule window to 2-3 hours.

The process for lock file maintenance is also very simple:

• Renovate deletes the existing lock file
• Renovate runs npm install or yarn install
• If the resulting lock file is different from the original, it creates a PR

Therefore the contents of the lock files are direct output from the respective package managers.

The most recent one seems to be in response to me having had to re-generate the lockfile and restore the peer dependency constraint for eslint, which resulted in fsevents being added to the lock - it seems renovate is having issues with optional dependencies.

This is a result of how optional dependencies work with package managers. Renovate runs on Linux, which doesn't use fsevents, so they won't be included in the lock file result.

If yarn or npm had reliable enough "update absolutely everything" commands instead of Renovate deleting the lock file fully then it's possible they themselves would preserve optional dependencies, but we found early on that not everything got upgraded.

And finally, we seemed to have had renovate open PRs that it shouldn't have: the config we're using for eslint-config-ackama matches what eslint-plugin-jest is using, yet eslint-config-ackama got PRs for individual packages which eslint-plugin-jest did not:

Please raise a discussion for this separately.

I don't know what logs are actually relevant - looking over them, they all seem to make logical sense on their own; I suspect this is an infrastructure issue.

There's no obvious bug evident, and it would require logs to identify if there is one. But so far it appears to be running as expected based on the feature described above.

Happy to provide logs upon request :)

FYI logs are available via the app portal for 3 days

I suspect that this is more of an infrastructure problem - specifically I'd say that renovate is being run every hour without any check on if its already done a lockfile refresh today.

There is no such logic/feature to check if a refresh was already done today. People are free to define any schedule for lock file maintenance, including continuous.