PR not opened when using Cargo workspace dependencies

[edmorley]

Is there an existing issue for this?

• 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 heroku/buildpacks-ruby#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 #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

[jurre]

@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.

[edmorley]

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 heroku/buildpacks-jvm#407), and so had thought it might be due to the grouping. But maybe it's some other regression?

[jurre]

Could it be related to something like conflicting transitive dependencies that differ between those projects? That would be my first guess

[ym-project]

I have the same problem with cargo's root workspace dependencies.

[ym-project]

It seems like dependabot starts to update such dependencies. Could you check it out?

[edmorley]

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.

[edmorley]

The bot just added a bunch of irrelevant GitHub issue tags - could someone remove them?

[heaths]

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.

[CodingAnarchy]

@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.