Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Permit overlapping rules #10160

Open
1 task done
jonhoo opened this issue Jul 7, 2024 · 1 comment
Open
1 task done

Permit overlapping rules #10160

jonhoo opened this issue Jul 7, 2024 · 1 comment
Labels
L: rust:cargo Rust crates via cargo service 💁 Relates to Dependabot features GitHub provides T: feature-request Requests for new features

Comments

@jonhoo
Copy link

jonhoo commented Jul 7, 2024

Is there an existing issue for this?

  • I have searched the existing issues

Feature description

After a lot of fiddling with dependabot rules for the Rust (well, cargo) ecosystem over the years, I thought I'd finally arrived at a dependabot configuration that follows Rust's preferred semantics for updates without too much noise:

  • Major versions should get dedicated PRs, should update Cargo.toml, and should happen in a timely fashion.
  • Minor/patch version updates should never touch Cargo.toml, should happen jointly in a single PR, and should happen on a regular-but-sparse cadence.

Unfortunately, no such luck; the setup I'd come up with requires multiple dependabot rules for the cargo package ecosystem, and that is disallowed, giving the error:

Update configs must have a unique combination of 'package-ecosystem', 'directory', and 'target-branch'. Ecosystem 'cargo' has overlapping directories.

They're not technically overlapping since they have ignore clauses that make them distinct, though I suspect it'd be quite difficult to have dependabot check for that property for arbitrary ignore blocks.

Ultimately, I'd love to see dependabot approach rules the same way it approaches the new(ish) groups, specifically:

Dependabot creates groups in the order they appear in your dependabot.yml file. If a dependency update could belong to more than one group, it is only assigned to the first group it matches with.

That is, for overlapping rules to be permitted where the first one that matches takes precedence. That would unlock use-cases like mine, which as far as I can tell at least cannot be achieved with dependabot's current configuration structure.

@jonhoo jonhoo added the T: feature-request Requests for new features label Jul 7, 2024
@github-actions github-actions bot added L: git:submodules Git submodules L: go:modules Golang modules L: rust:cargo Rust crates via cargo labels Jul 7, 2024
jonhoo added a commit to jonhoo/rust-ci-conf that referenced this issue Jul 7, 2024
@jonhoo
Copy link
Author

jonhoo commented Jul 7, 2024

Worth pointing out that with #4009, I could get pretty close with a single rule with multiple groups, though I'd have to settle for using a single cadence for all update types.

@jakecoffman jakecoffman added service 💁 Relates to Dependabot features GitHub provides and removed L: go:modules Golang modules L: git:submodules Git submodules labels Jul 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
L: rust:cargo Rust crates via cargo service 💁 Relates to Dependabot features GitHub provides T: feature-request Requests for new features
Projects
Status: No status
Development

No branches or pull requests

2 participants