Possible to group updates based on update-lockfile action?

[jwodder]

What would you like help with?

I would like help with my configuration

How are you running Renovate?

None

If you're self-hosting Renovate, tell us which platform (GitHub, GitLab, etc) and which version of Renovate.

No response

Please tell us more about your question or problem

I am considering using Renovate to manage automatic dependency updates to my Rust repositories. The key things I want for such updates are:

1. Cargo.lock (if present) should be updated whenever a new version of a dependency is released, but Cargo.toml should only be updated when a new version of a direct dependency is incompatible with the current version specifier.

   • E.g., if Cargo.toml specifies the dependency foo = "1.2.3", then upon the release of foo v1.3.0, Cargo.lock should be updated but Cargo.toml should not. When foo v2.0 is released, Cargo.toml should be updated to specify foo = "2.0", and Cargo.lock should be updated to match.
   • My understanding is that this is what the "rangeStrategy": "update-lockfile" setting does. So far, so good.

2. Dependency updates that only result in modifications to Cargo.lock should be grouped into a single PR each time Renovate runs.

3. Dependency updates that result in modifications to Cargo.toml should be realized as one PR per direct dependency; each such PR should just update a single line¹ in Cargo.toml along with whatever updates to Cargo.lock follow from that.

(I am aware that 2 and 3, taken together, are likely to lead to merge conflicts when more than one Renovate PR is open at once; as a side question, I'd appreciate any advice for dealing with this beyond just "Merge one PR and rebase the next one at a time.")

Now, I don't see a way in the configuration docs to get Renovate to do both 2 and 3 at the same time. Am I missing something, or should this become a feature request?

Logs (if relevant)

Logs

Replace this text with your logs, between the starting and ending triple backticks

Footnotes

1. Or multiple lines, for the occasional case where the same package appears under more than one of [dependencies], [dev-dependencies], and [build-dependencies]. ↩

[rarkins]

1. This should be the default behavior with rangeStrategy=auto, which defaults to rangeStrategy=update-lockfile
2. I'm not sure we support this directly just yet. matchUpdateTypes=patch,minor should be approximately the same if you use the traditional approach to Cargo.toml
3. This is the default behavior if you don't group them

[jwodder]

matchUpdateTypes=patch,minor should be approximately the same if you use the traditional approach to Cargo.toml

I don't know what you mean by "the traditional approach to Cargo.toml", but by my understanding of matchUpdateTypes, that option fails to do what I want for two reasons:

• If an indirect dependency (one listed in Cargo.lock but not Cargo.toml) receives a major version bump, it won't be included in the group, which is not what I want.

• If a direct dependency listed in Cargo.toml currently has a version specifier of the form 0.x.y, and then version 0.{x+1}.0 is released, the update will be included in the group, despite the fact that, per Cargo's version of SemVer, this is an incompatible update and thus Cargo.toml should be updated, which means I don't want it in the group.

[rarkins]

• If an indirect dependency (one listed in Cargo.lock but not Cargo.toml) receives a major version bump, it won't be included in the group, which is not what I want.

I don't think that's relevant. If a direct dependency of yours updates one of its own dependencies, and it's a major bump, but the API or functionality of the direct dependency doesn't change as a result, then you shouldn't worry yourself that it's a major bump - you have no breaking changes to deal with.

• If a direct dependency listed in Cargo.toml currently has a version specifier of the form 0.x.y, and then version 0.{x+1}.0 is released, the update will be included in the group, despite the fact that, per Cargo's version of SemVer, this is an incompatible update and thus Cargo.toml should be updated, which means I don't want it in the group.

Good point, but you can split this into two rules to accommodate it. You can use matchCurrentVersion to pick out versions <1.0.0 and group only updateTypes=patch updates and matchCurrentVersion=>1.0.0 and updateTypes=patch,minor

[jwodder]

I don't think that's relevant. If a direct dependency of yours updates one of its own dependencies, and it's a major bump, but the API or functionality of the direct dependency doesn't change as a result, then you shouldn't worry yourself that it's a major bump - you have no breaking changes to deal with.

I think we're talking past each other. Let me give an example situation: My package depends on apple = "^1.2.0", and apple depends on banana = "^1.0.0". apple then releases v1.3.0, which increases its banana dependency to "^2.0.0". Thus, I expect the apple version in Cargo.lock to get a minor bump and the banana version to get a major bump; Cargo.toml should be untouched.

If I haven't configured any packageRules, what is Renovate's default behavior here regarding PR creation? If I've declared a group for minor & patch updates, what happens then?

[rarkins]

I think we're talking past each other. Let me give an example situation: My package depends on apple = "^1.2.0", and apple depends on banana = "^1.0.0". apple then releases v1.3.0, which increases its banana dependency to "^2.0.0". Thus, I expect the apple version in Cargo.lock to get a minor bump and the banana version to get a major bump; Cargo.toml should be untouched.

Yes, that's how it should work by default in the latest version of Renovate.

If I haven't configured any packageRules, what is Renovate's default behavior here regarding PR creation? If I've declared a group for minor & patch updates, what happens then?

Default behavior is one PR per dependency, split between major and non-major. So you might get e.g. a lockfile-only PR for a minor update and a package file + lockfile update for a major update.

If you group, then you get multiple updates in a single PR based on what criteria you set.

[jwodder]

Default behavior is one PR per dependency, split between major and non-major. So you might get e.g. a lockfile-only PR for a minor update and a package file + lockfile update for a major update.

In the specific case of apple and banana that I described above, what's the default behavior? Is to create one PR to update apple and another PR to update banana?

[rarkins]

Renovate does not update transitive dependencies separately so banana would be updated as part of the Apple update