search

dependabot / dependabot-core

🤖 Dependabot's core logic for creating update PRs.
https://docs.github.com/en/code-security/dependabot
MIT License
4.71k stars 1.02k forks source link

"Could not resolve workspace root for path dependency" when crate is one directory under workspace root #10584

Closed divergentdave closed 1 month ago

divergentdave commented 2 months ago

Is there an existing issue for this?

Package ecosystem

cargo

Package manager version

1.81.0

Language version

1.81.0

Manifest location and content before the Dependabot update

https://github.com/divviup/janus/blob/a5252ea71bfbf73385e7aee28c1dfac97f72d01e/Cargo.toml

dependabot.yml content

https://github.com/divviup/janus/blob/a5252ea71bfbf73385e7aee28c1dfac97f72d01e/.github/dependabot.yml

Updated dependency

N/A

What you expected to see, versus what you actually saw

Dependabot is encountering an error when running on the following repository. I can reproduce this locally. The following command fails, when it should have succeeded.

[dependabot-core-dev] ~ $ bin/dry-run.rb --commit a5252ea71bfbf73385e7aee28c1dfac97f72d01e cargo divviup/janus
warning: parser/current is loading parser/ruby33, which recognizes 3.3.4-compliant syntax, but you are running 3.3.1.
Please see https://github.com/whitequark/parser#compatibility-with-ruby-mri.
=> cloning into /home/dependabot/tmp/divviup/janus
=> checking out commit a5252ea71bfbf73385e7aee28c1dfac97f72d01e
/home/dependabot/cargo/lib/dependabot/cargo/file_fetcher.rb:282:in `find_workspace_root': Could not resolve workspace root for path dependency /aggregator/Cargo.toml of /Cargo.toml (Dependabot::DependencyFileNotEvaluatable)
    from /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/sorbet-runtime-0.5.11444/lib/types/private/methods/call_validation.rb:270:in `bind_call'
    from /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/sorbet-runtime-0.5.11444/lib/types/private/methods/call_validation.rb:270:in `validate_call'
    from /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/sorbet-runtime-0.5.11444/lib/types/private/methods/_methods.rb:277:in `block in _on_method_added'
    from /home/dependabot/cargo/lib/dependabot/cargo/file_fetcher.rb:153:in `block in fetch_path_dependency_files'
    from /home/dependabot/cargo/lib/dependabot/cargo/file_fetcher.rb:134:in `each'
    from /home/dependabot/cargo/lib/dependabot/cargo/file_fetcher.rb:134:in `flat_map'
    from /home/dependabot/cargo/lib/dependabot/cargo/file_fetcher.rb:134:in `fetch_path_dependency_files'
    from /home/dependabot/cargo/lib/dependabot/cargo/file_fetcher.rb:90:in `block in path_dependency_files'
    from /home/dependabot/cargo/lib/dependabot/cargo/file_fetcher.rb:88:in `each'
    from /home/dependabot/cargo/lib/dependabot/cargo/file_fetcher.rb:88:in `path_dependency_files'
    from /home/dependabot/cargo/lib/dependabot/cargo/file_fetcher.rb:63:in `fetch_path_dependency_and_workspace_files'
    from /home/dependabot/cargo/lib/dependabot/cargo/file_fetcher.rb:54:in `fetch_files'
    from /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/sorbet-runtime-0.5.11444/lib/types/private/methods/call_validation.rb:270:in `bind_call'
    from /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/sorbet-runtime-0.5.11444/lib/types/private/methods/call_validation.rb:270:in `validate_call'
    from /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/sorbet-runtime-0.5.11444/lib/types/private/methods/_methods.rb:277:in `block in _on_method_added'
    from /home/dependabot/common/lib/dependabot/file_fetchers/base.rb:135:in `files'
    from /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/sorbet-runtime-0.5.11444/lib/types/private/methods/call_validation_2_7.rb:919:in `bind_call'
    from /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/sorbet-runtime-0.5.11444/lib/types/private/methods/call_validation_2_7.rb:919:in `block in create_validator_method_medium0'
    from bin/dry-run.rb:425:in `fetch_files'
    from bin/dry-run.rb:507:in `<main>'

Similar problems were reported in servo/servo#33402. I tried checking out d1117712d67fcfb5a16b39b80bccf0865029a4d3, which was the commit right before #10550 was landed, and a dry run succeeds with that code.

I added some print statements on top of the code on main, and I think what's happening is that this condition is too strict. Immediately before the above error, current_dir is equal to aggregator, and thus parent_dirs is -1, since there's no slashes in this relative path. Yet, this loop ignores the Cargo.toml manifest at the root of the repository, which is in fact the workspace manifest.

Native package manager behavior

N/A

Images of the diff or a link to the PR, issue, or logs

N/A

Smallest manifest that reproduces the issue

No response

mistydemeo commented 1 month ago

I've been seeing this in my Rust workspaces as well (for example, cargo-dist). Unfortunately, this means my PRs are filling up with "an unknown error occurred" comments, so I think I'm going to have to turn dependabot off for now.

alex commented 1 month ago

Thanks for fixing, how long does it take for the revert to make it to production?