lockfileMaintenance messes up with vulnerability alerts and schedules
#22524
Answered
by
rarkins
ferferga
asked this question in
Request Help
-
How are you running Renovate?Mend Renovate hosted app on github.com If you're self-hosting Renovate, tell us what version of Renovate you run.No response If you're self-hosting Renovate, select which platform you are using.None Was this something which used to work for you, and then stopped?It used to work, and then stopped Describe the problemThe real repository with this issue is jellyfin-vue. A minimal reproduction is located here The lockfieMaintenace option is messing the update logic of renovate in the following means:
I attached the full log of the run and also the specific parts where I think my points are better showcased. Relevant debug logsFull logtauri-deps update being ignoredHave you created a minimal reproduction repository?I have linked to a minimal reproduction in the description above |
Beta Was this translation helpful? Give feedback.
Answered by
rarkins
Jun 1, 2023
Replies: 1 comment 10 replies
-
|
Please ensure that the renovate config is minimal. The config right now is large, which implies it's either not minimal, or it's a very narrow edge case |
Beta Was this translation helpful? Give feedback.
10 replies
-
|
@rarkins Yes, correct. No PR is the reproduction (that's why I also wanted to add all the npm dependencies in my original reproduction, so there was a clear hint that everything was running correctly and my config was not the issue). You can check this repo with renovate running without the For summarising, I created the following repositories:
|
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure you're understanding my question about minimal. For example, are you saying that if you remove the this line from config then the problem goes away? https://github.com/ferferga/renovate-repro2/blob/c8ec185e47646a13ed8157f1b591b1a45786f1a5/.github/renovate.json#L12 This would be very surprising if so. If you are telling me that the problem truly only occurs with this very specific 37 lines of config, and removing any line of it fixes the problem, then it's evidently a very narrow edge case which is not a priority to fix compared to any other bug we have. If instead you can provide an actual minimal reproduction then we'll have a better idea of whether this is an edge case or something we should prioritize. |
Beta Was this translation helpful? Give feedback.
-
|
@rarkins Sorry. Here is the repo with the minimal config I could get: https://github.com/ferferga/renovate-repro4 As you can see in the log, I should get updates from You can check how it's working fine in these repos:
PS: As a side note, I always did the test by deleting and recreating each repository iteration, so we're sure all the config is fully fresh and no stale PRs or branches are polluting Renovate's behaviour. Full log of renovate-repro4Full log of renovate-repro5Full log of renovate-repro6 |
Beta Was this translation helpful? Give feedback.
-
|
Here's what I found: Ignore the security update - that's a red herring. Security updates intentionally bypass grouping and schedules, so that's why it popped up on its own, by design. The I recommend against separateMajorMinor=true, but it's not the root cause of anything. It just makes the remaining config slightly longer. You can see the "fixed" repo PR here: renovate-reproductions/22524#2 Check out the config within the same repo |
Beta Was this translation helpful? Give feedback.
Answer selected by
ferferga
-
|
@rarkins Thank you very much, that definitely works as I want! Is a PR welcome for adding a warning/note to the documentation regarding this behaviour? The fact that schedule goes from the most restrictive to the least restrictive in the order of preference. In my case, given no schedule were given for the other update types, I expected them to use the default one (since I didn't had any defined), which is immediate. About the vulnerability alerts behaviour: Yes, that's the behaviour I expected (and I think people expects too). I want them grouped, but I found it the issue was in my end (faulty config) as well, so all of this is resolved! |
Beta Was this translation helpful? Give feedback.
-
|
It's common to have a schedule for lock file maintenance, so that part is not the problem. The problem is when grouping together all updates for a particular manager, as that includes lock file maintenance too. Realistically I doubt there's a place in the documentation where we could put such a warning which would help. In future we plan to make it impossible to group lock file maintenance PRs with others, so that would be a way of avoiding the problem |
Beta Was this translation helpful? Give feedback.
-
|
@rarkins That sounds good to me! But when designing this, please allow to retain the ability to group all lockfiles together (from different managers, different files, etc). It makes sense to not group that update type with the others, but it's useful to have all the lockfiles together. I'm closing this discussion and marked your reply as an answer👍! |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Here's what I found:
Ignore the security update - that's a red herring. Security updates intentionally bypass grouping and schedules, so that's why it popped up on its own, by design.
The
matchManagers=cargorule matches lock file maintenance updates too. i.e. all cargo updates including lock file maintenance are together. Then, the schedule for lock file maintenance applies to that branch too.I recommend against separateMajorMinor=true, but it's not the root cause of anything. It just makes the remaining config slightly longer.
You can see the "fixed" repo PR here: renovate-reproductions/22524#2
Check out the config within the same repo