feat(cargo): support range=update-lockfile

[szlend]

Changes

Adds update-lockfile rangeStrategy support to the cargo manager.

Context

• closes Support rangeStrategy=update-lockfile for Cargo #22820

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[CLAassistant]

All committers have signed the CLA.

[viceice]

please sign the cla, otherwise we can't review

[szlend]

Should I also update the default (auto) range strategy now that we support update-lockfile?

[viceice]

Should I also update the default (auto) range strategy now that we support update-lockfile?

yes and please don't force push. we squash merge, so no worry about git history

[viceice]

needs more tests for coverage

[szlend]

• Added a hack to handle already updated dependencies. This is necessary when a preceding cargo command updates a later dependency.
• Implemented updateLockedDependency which improved error reporting significantly.

I also tested this on a number of personal projects and haven't noticed any issues other than the previously mentioned Detected empty commit message in the Dashboard when something fails. Please re-review.

[rarkins]

Let's say that a PR already exists and is up-to-date. Will Renovate re-run cargo update commands every single time it runs on the repo/branch, or does it have a way of knowing that the locked version is already updated and no command is necessary?

[szlend]

Let's say that a PR already exists and is up-to-date. Will Renovate re-run cargo update commands every single time it runs on the repo/branch, or does it have a way of knowing that the locked version is already updated and no command is necessary?

Is this something each manager has to handle manually? I implemented the 'already-updated' case in updateLockedDependency so technically Renovate should be aware of the state of the lockfile at least.

Edit: If the question is referring to the hack I wrote to skip already updated dependencies, this is only used when a preceding command in a list of batched cargo update commands updates a later dependency in the batch. E.g. an update to serde-json also triggers an update to serde for whatever reason. Because we send a prebuild list of shell commands there's no other (simple) way to handle this that I could think of. I guess we could catch failures, parse stderr to figure out which dependencies are already up to date. Then retry updateArtifacts without those dependencies recursively until everything is updated. But that's FAR more complicated.

[rarkins]

I think you have it covered already with the already-updated part. You can verify that by running Renovate twice - first time to create the branch and second to check that no cargo update command was run

[szlend]

I think you have it covered already with the already-updated part. You can verify that by running Renovate twice - first time to create the branch and second to check that no cargo update command was run

The issue is within the same run. Between batched cargo update commands.

[viceice]

please rename and make private, create a new updateArtifacts which called the renamed function, so recursion limit isn't part of the public API.

[szlend]

This is exactly how it's done in other managers, i.e. bundler. I'm really getting tired of this back and forth. Please be respectful of my time. I will leave some time for you to do a final review pass. Any other issues you can fix yourself. I'm happy to use this branch for my use case.

[rarkins]

I think it's best that we close this and someone else can pick it up to completion

[rarkins]

If anyone else has the time to pick this up and open an updated PR, please base it off @szlend's branch and let's make sure to name him as co-author in the final commit to main