dependabot
PR not opened when using Cargo workspace dependencies
Is there an existing issue for this?
- [X] I have searched the existing issues
Package ecosystem
Cargo
Package manager version
1.71.1
Language version
1.71.1
Manifest location and content before the Dependabot update
https://github.com/edmorley/testcase-dependabot-cargo-workspace-not-updated/blob/main/Cargo.toml https://github.com/edmorley/testcase-dependabot-cargo-workspace-not-updated/blob/main/example-crate-one/Cargo.toml https://github.com/edmorley/testcase-dependabot-cargo-workspace-not-updated/blob/main/example-crate-two/Cargo.toml
dependabot.yml content
https://github.com/edmorley/testcase-dependabot-cargo-workspace-not-updated/blob/main/.github/dependabot.yml
Updated dependency
No response
What you expected to see, versus what you actually saw
I expected Dependabot to open a PR updating the Rust crates libcnb, libcnb-test and libherokubuildpack from 0.13.0 to the latest version 0.14.0, since newer versions exist. This PR should edit the root Cargo.toml, since that's where those "workspace defined dependencies" exist.
Note: Dependabot successfully updates these dependencies on some of our other repos (for example https://github.com/heroku/buildpacks-ruby/pull/192). These other repos were also using grouped Dependabot, however, those other repos aren't using the "dependencies defined in workspace root" feature of Cargo workspaces - so I presume that must be the difference? Dependabot does support Cargo workspaces in general though thanks to https://github.com/dependabot/dependabot-core/pull/5794 (we've had PRs for single/ungrouped dependencies before).
Native package manager behavior
No response
Images of the diff or a link to the PR, issue, or logs
Dependabot logs: https://github.com/edmorley/testcase-dependabot-cargo-workspace-not-updated/network/updates/713389708
In particular, it seems Dependabot finds the updated crates:
updater | 2023/08/24 13:16:32 INFO <job_713389708> Starting grouped update job for edmorley/testcase-dependabot-cargo-workspace-not-updated
updater | 2023/08/24 13:16:32 INFO <job_713389708> Found 1 group(s).
updater | 2023/08/24 13:16:32 INFO <job_713389708> Starting update group for 'libcnb'
updater | 2023/08/24 13:16:32 INFO <job_713389708> Checking if libcnb-test 0.13.0 needs updating
proxy | 2023/08/24 13:16:32 [022] GET https://crates.io:443/api/v1/crates/libcnb-test
proxy | 2023/08/24 13:16:33 [022] 200 https://crates.io:443/api/v1/crates/libcnb-test
updater | 2023/08/24 13:16:33 INFO <job_713389708> Latest version is 0.14.0
But then decides afterwards it cannot update to it here?
updater | 2023/08/24 13:16:36 INFO <job_713389708> Requirements to unlock update_not_possible
updater | 2023/08/24 13:16:36 INFO <job_713389708> Requirements update strategy bump_versions
updater | 2023/08/24 13:16:36 INFO <job_713389708> No update possible for libcnb-test 0.13.0
Smallest manifest that reproduces the issue
No response
@edmorley I've not been able to dig into why this update was not possible specifically, but I did verify if it was related to grouped updates, and it seems like it's not, meaning that we also don't see an update without grouping enabled on this reproduction. There are various reasons why that could happen, and this one may or may not be valid, but that'll require more investigation.
Ah thank you.
The reason why I thought this was related to grouped updates, was that we have successfully had updates to the repo root Cargo.toml from Dependabot prior to us enabling grouping (eg https://github.com/heroku/buildpacks-jvm/pull/407), and so had thought it might be due to the grouping. But maybe it's some other regression?
Could it be related to something like conflicting transitive dependencies that differ between those projects? That would be my first guess
It seems like dependabot starts to update such dependencies. Could you check it out?
I've been able to confirm that this doesn't seem related to the grouping feature, but instead it seems that Dependabot just doesn't work well with the Cargo workspace dependencies feature.
I've updated the issue title accordingly.
The bot just added a bunch of irrelevant GitHub issue tags - could someone remove them?
Is a PR not opened at all, or it's just not correct? Put another way, is there any indication a dependency needs to be updated? We plan on using workspace dependencies for a large mono repo as we do with all our other languages' mono repos for centralized management.
@heaths I'm not sure about the issue that @edmorley reported, but I came here to report a similar issue with workspaces - we see Dependabot opening some PRs, but they do not have any actual updates in them. There are also far fewer PRs than are actually needed to update the dependencies.
cargo update [crate] in the workspace root works as expected, but the Dependabot PR is either not created, or contains only "cleanup" where lines are moved around.
The status quo here appears to be that for dependencies whose version comes from [workspace.dependencies] (i.e., dependencies specified with {crate}.workspace = true), they simply do not receive any updates that require bumping the version in Cargo.toml. They do receive semver-compatible updates (i.e., ones that can happen only with Cargo.lock updates).
Groups updates are not related.
When can necessary Cargo.toml upgrades be expected? For example
rand = "0.8.5" # -> 0.9.1
to let a CI build automatically check for breaking changes?
I was hoping to get it work with mainmatter/cargo-autoinherit (I highly recommend it). Continues to detect possible bumps but unfortunately still does not create Pull-Requests.
This issue is should be fixed by https://github.com/dependabot/dependabot-core/pull/13201
So I think we can safely close this issue. 🎉
If anyone still has reproduction cases where dependabot fails, please comment with them. Or better yet, open a new issue.
@stefnotch I just tried to verify this was fixed, but am now encountering an error that's blocking Dependabot from running: #13345 / #13359.