-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Comments
Thoughts on doing this in stages? Adding |
Fine with doing it in stages, just wanted to create an issue that covers the majority of these feature requests. |
For npm at the moment would setting |
@siddharthvp yep 👍 |
Sorry if this appears unrelated – but would a combo like the following also work as of now?
(The intent is to get regular dependency updates daily and devDependency updates monthly.) |
@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). |
+1 for adding I believe that it is currently possible to only produce pull requests for 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. |
Currently, Dependabot offers two ways of opting dependencies in or out of updates:
allow
andignore
. The main differences (from a config file functionality standpoint) are:allow
has the ability to specifydependency-type
's (e.g.development
,production
) to allow a certain number of dependenciesignore
has the ability to opt out of certainversions
, whileallow
can't opt you in to certain versions (e.g. onlyallow
updates onx.y.z
notx+1.y.z
).It certainly feels useful to be able to write something like:
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
andignore
run at different times, so potentially we might want to unify this, or further clarify this behavior.The text was updated successfully, but these errors were encountered: