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

If a dependabot.yml file with a limited npm allow section exists all Security updates are disabled #5845

Open
1 task done
davidmurdoch opened this issue Oct 7, 2022 · 6 comments
Labels
F: configuration-file L: javascript:npm npm packages via npm T: bug 🐞 Something isn't working

Comments

@davidmurdoch
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

Package ecosystem

npm

Package manager version

6

Language version

16

Manifest location and content before the Dependabot update

No response

dependabot.yml content

Please see the documentation for all configuration options:

https://docs.github.com/github/administering-a-repository/configuration-options-for-dependency-updates

version: 2
updates:

  • package-ecosystem: "npm"
    directory: "/" # Location of package manifests
    schedule:
    interval: "daily"
    allow:
    • dependency-name: "ganache"
      reviewers:
    • "trufflesuite/truffle-core-devs"

Updated dependency

No response

What you expected to see, versus what you actually saw

Add a dependabot.yml to a project shouldn't change the behavior of the GitHub Dependency Security Settings, but it does.

Native package manager behavior

No response

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

Adding a dependabot.yml causes security updates to fail:

image

Smallest manifest that reproduces the issue

No response

@davidmurdoch davidmurdoch added the T: bug 🐞 Something isn't working label Oct 7, 2022
davidmurdoch added a commit to trufflesuite/truffle that referenced this issue Oct 7, 2022
The existence of this file with this configuration disables all security updates. See: dependabot/dependabot-core#5845
@jeffwidman jeffwidman added the L: javascript:npm npm packages via npm label Oct 8, 2022
@jeffwidman
Copy link
Member

👋 I'm a little confused...

Dependabot PR's that fix security updates are also version update PR's and subject (with certain exceptions) to the configuration in dependabot.yml. Your example dependabot.yml file only allows updates to ganache... so PR's for all other dependencies can't be created. So I'm not really surprised that Dependabot complains that it can't create a version update PR for other deps like thenify...

How is this not working as expected?

@davidmurdoch
Copy link
Author

davidmurdoch commented Oct 8, 2022

It seems impossible to enable security updates while also enabling limited all-version update PRs via config.

I've consulted with 4 other engineers on this, each with over 10 years experience in software development, and none of them expected this behavior. My expectation seems like a reasonable default to me.

@haltman-at
Copy link

So how would one set the config to achieve the desired goal here, then? (Enabling the usual security updates but also enabling all-version updates for one particular package.) Is there any way to do so?

I should note in addition to what @davidmurdoch has said that a bunch of us looked at the documentation and, from the documentation, did not expect this behavior. If this is the intended behavior, the docs need to be a lot clearer on this point.

@jeffwidman
Copy link
Member

jeffwidman commented Oct 10, 2022

So if i understand, what you want is the following:

  1. enable security updates for all deps
  2. enable non-security-related version updates for a subset of deps

Is that correct?

If so, I'm pretty sure there's a way to configure that, but I do agree in this case it's not clear at first glance how to do it... because I have to go look it up myself! 😄

@haltman-at
Copy link

Yup, that's the idea.

If you look at the documentation for allow, nowhere does it say that it in any way limits updates, that things outside of it are thereby disallowed; therefore I inferred that it allows you to turn other things on, and would not turn off the default behavior of getting security updates.

@dforesman
Copy link

Bumping this as it affects my organization, which has been using Dependabot for internal updates for years, and recently adopted Github Advanced Security.

We've been enjoying thousands of automated internal updates per year from our private NPM registry with Dependabot, but are now finding that the allow filtering that supports it is disabling security updates across our stack; an unacceptable outcome in our industry.

I agree with the posters in this thread who have described this behavior as counter-intuitive. In fact, it strikes me as such a fundamental oversight, I'm having trouble wrapping my head around it. If there is no way to filter out version updates without also filtering security updates, it leaves users either fundamentally insecure, or pummeled with constant version update PRs for every dependency in the project. It essentially removes the distinction between version updates and security updates, which strikes me as a bug.

To make matters worse - and further support that this is a bug - Dependabot itself reports 'No ignore conditions found' when queried for the packages that are being blocked from security updates.

  1. enable security updates for all deps
  2. enable non-security-related version updates for a subset of deps

If so, I'm pretty sure there's a way to configure that, but I do agree in this case it's not clear at first glance how to do it... because I have to go look it up myself! 😄

@jeffwidman were you ever able to find a viable way to configure this behavior? For myself, my organization, and every engineer I've talked to, this scenario is the core use-case for Dependabot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
F: configuration-file L: javascript:npm npm packages via npm T: bug 🐞 Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants