Open asciimike opened 3 years ago
Thoughts on doing this in stages? Adding dependency-type
to ignore
would be a pretty straight forward change compared to adding versions
to allow
.
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 allow: - dependency-type: production
disable the updates for devDependencies? I missed that option while going through the docs earlier.
would setting
allow: - dependency-type: production
disable the updates for devDependencies
@siddharthvp yep 👍
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.)
@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 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.
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 https://github.com/dependabot/dependabot-core/issues/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.