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

Make allow and ignore symmetric #3479

Open
asciimike opened this issue Apr 12, 2021 · 7 comments
Open

Make allow and ignore symmetric #3479

asciimike opened this issue Apr 12, 2021 · 7 comments
Labels
F: configuration-file F: dependency-ignores Allow excluding certain versions T: feature-request Requests for new features

Comments

@asciimike
Copy link
Contributor

Currently, Dependabot offers two ways of opting dependencies in or out of updates: allow and ignore. The main differences (from a config file functionality standpoint) are:

  • allow has the ability to specify dependency-type's (e.g. development, production) to allow a certain number of dependencies
  • ignore has the ability to opt out of certain versions, while allow can't opt you in to certain versions (e.g. only allow updates on x.y.z not x+1.y.z).

It certainly feels useful to be able to write something like:

updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    ignore:
      - dependency-type: "development"

Which would fulfill issues like #3475

We also offer a @dependabot ignore command without a corresponding @dependabot allow command, though dependabot updates everything by default, so allow might be redundant, unless you're trying to opt back in after you've opted out.

As an internal implementation note, I believe allow and ignore run at different times, so potentially we might want to unify this, or further clarify this behavior.

@feelepxyz
Copy link
Contributor

Thoughts on doing this in stages? Adding dependency-type to ignore would be a pretty straight forward change compared to adding versions to allow.

@asciimike
Copy link
Contributor Author

Fine with doing it in stages, just wanted to create an issue that covers the majority of these feature requests.

@siddharthvp
Copy link

For npm at the moment would setting allow: - dependency-type: production disable the updates for devDependencies? I missed that option while going through the docs earlier.

@feelepxyz
Copy link
Contributor

would setting allow: - dependency-type: production disable the updates for devDependencies

@siddharthvp yep 👍

@siddharthvp
Copy link

Sorry if this appears unrelated – but would a combo like the following also work as of now?

updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: daily
    allow:
      - dependency-type: production

  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: monthly
    allow: 
      - dependency-type: development

(The intent is to get regular dependency updates daily and devDependency updates monthly.)

@asciimike
Copy link
Contributor Author

@siddharthvp your head is in the right place, but unfortunately we don't currently support multiple schedules for the same ecosystem/directory pair. It's something we've considered, but it'll probably be a little further out (we're working on #2219 now).

@humphrey
Copy link

+1 for adding dependency-type to ignore if it's a straightforward change.

I believe that it is currently possible to only produce pull requests for dependency-type: "production" but it would be nice for them to be completely removed on the dependabot list.

Use case: I don't care about all of the security updates to "express" if it's only used in my web-based project to power hot-reloading during development.

@jeffwidman jeffwidman added F: configuration-file F: dependency-ignores Allow excluding certain versions and removed 🛑 on-hold labels Feb 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
F: configuration-file F: dependency-ignores Allow excluding certain versions T: feature-request Requests for new features
Projects
None yet
Development

No branches or pull requests

5 participants