Renovate: Dependency Prioritization

[chriscantu]

What would you like Renovate to be able to do?
AS A Pro (Enterprise) Renovate User
I WANT TO be able to prioritize some dependencies over others
SO THAT I can ensure critical dependencies are updated first

Describe the solution you'd like
For large scale applications with lots of dependencies, we would like the ability to configure prioritization for certain dependencies which are more mission critical. In the case where a repo has set a limit for the # of PRs that can be submitted, renovate would close a lower priority PR when a more important is queued. Also, Renovate should apply a label indicating the configured priority assigned to the dependency so it's clear for the maintainers which updates are more important.

Describe alternatives you've considered
To date, we apply labels specifying our priority based on the "packagePatterns" . However if our queue is full, new higher priority PRs are not submitted. We want to be able to see those high priority updates as soon as possible.

Additional context
N/A

[rarkins]

Which limit are you most concerned with? prConcurrentLimit?

[qswitcher]

I work with @chriscantu. Yes prConcurrentLimit is the limit we're referring to.

[rarkins]

How sure are you that you’d want to close existing PRs that no longer fit in the top X concurrent priority? I would think that could cause more noise than it saves at times.

I really like the idea, trying to think how “Priority” can be applied genetically and widely for different use cases too.

[qswitcher]

What prioritization does Renovate do today when creating PRs? That is, if 100 dependencies are out of date, what criteria does it use to create PRs? especially if there is a prConcurrentLimit. What would be sufficient for us is if we could basically tell it "If you do a scan and there are 100 updates you need to make, but you only have room for 10 PRs, use these rules to sort based on priority".

Closing PRs would be a nice to have, but we could live without it just knowing that _when there is space available_, Renovate will only create PRs for the current highest priority package rules. Scheduling might work, but seems cumbersome since it would require playing games like: priority 1 gets scheduled every hour, priority 2 once a day, priority 3: once a week, etc, and would require a lot of tuning to make sure that priority 1 PRs _tend_ to fill up the prConcurrentLimit before lower priorities do.

[rarkins]

Currently prioritisation is done on update type: pin, digest, patch, minor, match. Ie raise the “easiest” ones first.

[chriscantu]

Another simple option instead of closing PR's is ignoring the limit and
always opening a top priority dependency.

On Mon, Jun 10, 2019 at 2:18 PM Rhys Arkins [e-mail]
wrote:

Currently prioritisation is done on update type: pin, digest, patch,
minor, match. Ie raise the “easiest” ones first.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/renovatebot/pro/issues/57?email_source=notifications&email_token=AAARC6XWBFXYUSY5ZP3M36LPZ2SHJA5CNFSM4HWMS6JKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXK5QGI#issuecomment-500553753,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAARC6RLXABJ6M6DKHTOGDLPZ2SHJANCNFSM4HWMS6JA
.

[rarkins]

Yep, that's another good idea. BTW I think schedule and priority can live side by side too. Of course it would be complex if you really use both, but we should retain the ability to configure both.

[rarkins]

Moving this to the main repo as it will need to be implemented there as part of core

[rarkins]

Something else we need to now decide:

Presumably it makes sense to name it like prPriority and make it a number. But what should be the default? No number, or a "mid" range number. Having a mid number would all you to not only prioritise but also de-prioritise certain dependencies without needing to add a priority to all.

So I'm thinking either a 1-9 scale with default 5, or set the default to 0 and let people configure positive or negative numbers.

[qswitcher]

Personally I prefer the latter of defaulting to 0 and allowing arbitrary positive and negative numbers for maximum flexibility.

[herb-ng]

hello, I work with @chriscantu and I will be working on this.

[rarkins]

@herb-ng that's awesome. Summing up what was discussed here:

• New config option prPriority that is of type 'integer' and defaults to 0
• Disable CLI and env for this option (in its config definition)
• Use prPriority as the first sorting criteria in https://github.com/renovatebot/renovate/blob/master/lib/workers/repository/process/sort.js

Note: we don't currently have any existing config options with type integer so there's a chance there may need to be some code added just for it.

[renovate-bot]

:tada: This issue has been resolved in version 19.38.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: