6 ms·

GitHub's dependabot is causing a ton of "spam" in our frontend (Angular) repositories, as it seemingly opens 1-5 PRs per day to bump random dependencies. I real

GitHub's dependabot is causing a ton of "spam" in our frontend (Angular) repositories, as it seemingly opens 1-5 PRs per day to bump random dependencies. I really hope this does not become common practice for our Go repositories. Is there an option to tell dependabot "make one PR per week at most, please, and bundle your changes"?

Cthulhu_ 5y ago
Part of that is the Node / JS ecosystem that churns out libraries for every tiny thing. The Go ecosystem is a lot more streamlined; adding dependencies is frowned upon, building small libraries is frowned upon, etc. That said, if it's just version bumps then they should be bundled. But what about security issues? Those need to be fixed and updated asap.
gherkinnn 5y ago
Here's some information on these "vulnerabilities": https://overreacted.io/npm-audit-broken-by-design/ https://overreacted.io/npm-audit-broken-by-design/ As far as I'm concerned, there's no need for Dependabot to create PRs. The notifications in the security tab are enough. Mark the unnecessary ones as benign.
- staticassertion 5y ago
  The PRs are really helpful when you do actually want to update.
  - gherkinnn 5y ago
    You can have Dependabot create a PR by hitting a button somewhere in the vulnerability details.
- dane-pgp 5y ago
  And here's the HN discussion on that thought-provoking post: https://news.ycombinator.com/item?id=27761334 https://news.ycombinator.com/item?id=27761334
starefossen 5y ago
The amount of pull requests from dependency updates can become more manageable if you enable GitHub’s Auto Merge feature[1] [1] https://docs.github.com/en/github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request https://docs.github.com/en/github/collaborating-with-pull-re...
- ilammy 5y ago
  Exactly what you want to have: get a bot merge fixes for security issues prepared by another bot without any human oversight. Then let Copilot add features to your software automatically as well.
- dmitriid 5y ago
  You can't enable granular auto merges: I'm fine with auto merging minor/security update PRs from dependabot. Not anything else. You can't set up that.
  - starefossen 5y ago
    You could probably use a GitHub Action and check the API for author of the pull request if you want to require additional verification. If have done something similar with auto accepting docs-only pull requests in the past.
    - asciimike 5y ago
      Dependabot PM here: We've provided an action that will provide metadata (e.g. semver bump) that you can use to enable granular automerge. See https://github.com/dependabot/fetch-metadata/#enabling-auto-merge https://github.com/dependabot/fetch-metadata/#enabling-auto-... for an example.
skybrian 5y ago
This seems like good motivation to prune your dependencies if they’re getting out of hand. Of course, easier said than done, but at an ecosystem level maybe it will help?
- mukesh610 5y ago
  Well angular repositories tend to have tons of dependencies.
- tailspin2019 5y ago
  In the case of NPM, the only way to not have your dependencies be “out of hand”, is to not use NPM. /s (but also, for realsies)
rudian 5y ago
Disable it. If you don’t want to, limit it to weekly or monthly. I agree that Dependabot is super noisy especially by default.
- whymarrh 5y ago
  Yup, there's quite a few different configuration options available: https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates https://docs.github.com/en/code-security/supply-chain-securi...
koblas 5y ago
The "biggest" problem in the JavaScript ecosystem (NPM) is that dependadabot doesn't know how to discriminate between dependancies and devDepandancies. I don't really care if jest includes a package that has a regex issue. It's not production code. I do care if babel introduces a backdoor, but somehow they're treated with equal importance.
- leftshift 5y ago
  It depends, attacks via build pipelines can be devastating.
  - tailspin2019 5y ago
    Yep. Unfortunately it’s not clear cut that we don’t have to worry about devDependencies vulnerabilities.
- greysteil 5y ago
  PM for security products at GitHub here. Totally agree. The good news is that I think GitHub is in a position to fix this - expect progress in the next 12 months. One change that's needed here is data for each vulnerability on whether it's ever relevant in development. The advisory database that powers GitHub's security alerts (and npm audit, and NuGet audit) now has a dedicated curation team and is ready to curate more ecosystems and more information. That data then needs to be hooked up with GitHub's security alerting logic. That shouldn't be too difficult - we already detect whether a dependency is used in development or production, and the team here is growing. Finally, for this to work we'd need a new UI concept for vulnerabilities you aren't affected by. We're already working on functionality with a very similar requirement (one that tells you whether you're using the vulnerable function within a dependency). I can't make promises, but I can say that GitHub has an increasing amount of energy. Expect progress :-)
greysteil 5y ago
PM for security products at GitHub here (and one of the original authors of Dependabot). Sorry to hear that. I wouldn't expect us to be telling you about 1-5 security issues a day - do you maybe have (non-security) version updates enabled? If so and they feel like spam to you I'd recommend turning them off. (I wish I had a better suggestion, but until Dependabot supports grouped updates it sounds like it just isn't right for you.) Dependabot doesn't support grouped updates yet but we hear the feedback and the team wants to work on them. Most of the investment in Dependabot recently gone towards improving our infrastructure and improving the experience for security updates. The team is still relatively small (it's 7 people), and supporting a service like this at GitHub scale is hard, but we're keen to keep improving.
- plasma 5y ago
  HN is great, can I chime in with some feedback too, for NuGet I’m seeing Dependabot open separate PRs for the same dependency that’s out of date in the one repo that has multiple projects that relate to each other (they reference one another in csproj files). They thus also need to be updated together, but I wish one PR was opened to update the dependencies in all projects at once, instead of multiple PRs I to merge. PS: I think you should highlight dependabot updates on the Security tab in GitHub repo, I thought it was on before (but was actually just the security notices) because dependabot itself is hidden away in Insights -> Dependency graph -> Dependabot which was a bit surprising.
  - greysteil 5y ago
    Feature requests always welcome! I'll pass it on to the Dependabot team.
    - plasma 5y ago
      Thank you
      - asciimike 5y ago
        Let me know if https://github.com/github/roadmap/issues/148 https://github.com/github/roadmap/issues/148 is in the right spirit of what you're aiming for. I think that what will get implemented will be a bit broader (covering version updates and security updates) and will allow for grouping by manifest, language, vulnerability, and potentially arbitrary labeling in the config file.
staticassertion 5y ago
It seems to primarily be a frontend thing. I get tons and tons of them, it's really annoying.
hiq 5y ago
I also get a lot of spam from dependabot because of prereleases, I wish they would fix this bug: https://github.com/dependabot/dependabot-core/issues/2547 https://github.com/dependabot/dependabot-core/issues/2547 As others have pointed out, you can opt for daily / weekly or monthly updates, I'll stick to monthly until they fix this bug.
- greysteil 5y ago
  Hmmm, it's been a long time since I worked on Dependabot Core, but I think I can fix that one - we just need to special case `native-mt` as a version type (as opposed to applying standard Maven version comparison rules on it). I'll try and get a PR in today and will tag you. Update: https://github.com/dependabot/dependabot-core/pull/4077 https://github.com/dependabot/dependabot-core/pull/4077
boarnoah 5y ago
I usually ignore those and bundle a bunch in a single PR. The worst I found was another team which merges in depandabot PR's one by one. Their git history isn't pleasant to look through :(
- karlding 5y ago
  The git log command has a --perl-regexp flag [0], which allows you to filter commits that match a Perl-style regular expression. I guess in that situation you could specify a regular expression that excludes dependabot in --author. If typing --perl-regexp gets old, you can always alias it or add a repo/global config option via grep.patternType [1]. Or you can create an alias for adding the less-powerful --invert-grep [2]. [0] https://git-scm.com/docs/git-log/2.32.0#Documentation/git-log.txt---perl-regexp https://git-scm.com/docs/git-log/2.32.0#Documentation/git-lo... [1] https://git-scm.com/docs/git-config/2.32.0#Documentation/git-config.txt-greppatternType https://git-scm.com/docs/git-config/2.32.0#Documentation/git... [2] https://git-scm.com/docs/git-log/2.32.0#Documentation/git-log.txt---invert-grep https://git-scm.com/docs/git-log/2.32.0#Documentation/git-lo...
X6S1x6Okd1st 5y ago
Yup, my PR review requested page is near useless because of all of the dependabot PRs.
skipants 5y ago
A setting I turned on to make it more manageable is to ignore patch updates and have dependabot only make PRs for major & minor version bumps.
hakre 5y ago
it was easy: block the user. then it got harder: create one branch that blocked the dependabot branch. then it got harder again: create 00 00 00 - FF FF FF branches (let it run with parallelism and over night). github support is not helpful on this.
pabs3 5y ago
Not recording exact dependency versions seems like the right way to stop those PRs from happening.
asciimike 5y ago
Dependabot PM following up a few days late > Is there an option to tell dependabot "make one PR per week at most ... You can set the `open-pull-requests-limit: 1` (https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates#open-pull-requests-limit https://docs.github.com/en/code-security/supply-chain-securi...) and the `schedule.interval: weekly` to limit the number of created PRs to one per week > ... and bundle your changes"? We've referred to this feature as "grouped updates" and it's tracked on the roadmap: https://github.com/github/roadmap/issues/148 https://github.com/github/roadmap/issues/148 Potentially using `allow: direct` (https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates#allow https://docs.github.com/en/code-security/supply-chain-securi...) to ignore the random sub dependencies, or ignoring minor versions (https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates#ignore https://docs.github.com/en/code-security/supply-chain-securi...) of some/all dependencies might help reduce that noise.

Cthulhu_ 5y ago

Part of that is the Node / JS ecosystem that churns out libraries for every tiny thing. The Go ecosystem is a lot more streamlined; adding dependencies is frowned upon, building small libraries is frowned upon, etc. That said, if it's just version bumps then they should be bundled. But what about security issues? Those need to be fixed and updated asap.

gherkinnn 5y ago

Here's some information on these "vulnerabilities": https://overreacted.io/npm-audit-broken-by-design/ https://overreacted.io/npm-audit-broken-by-design/ As far as I'm concerned, there's no need for Dependabot to create PRs. The notifications in the security tab are enough. Mark the unnecessary ones as benign.

staticassertion 5y ago
The PRs are really helpful when you do actually want to update.
- gherkinnn 5y ago
  You can have Dependabot create a PR by hitting a button somewhere in the vulnerability details.
dane-pgp 5y ago
And here's the HN discussion on that thought-provoking post: https://news.ycombinator.com/item?id=27761334 https://news.ycombinator.com/item?id=27761334

starefossen 5y ago

The amount of pull requests from dependency updates can become more manageable if you enable GitHub’s Auto Merge feature[1] [1] https://docs.github.com/en/github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request https://docs.github.com/en/github/collaborating-with-pull-re...

ilammy 5y ago
Exactly what you want to have: get a bot merge fixes for security issues prepared by another bot without any human oversight. Then let Copilot add features to your software automatically as well.
dmitriid 5y ago
You can't enable granular auto merges: I'm fine with auto merging minor/security update PRs from dependabot. Not anything else. You can't set up that.
- starefossen 5y ago
  You could probably use a GitHub Action and check the API for author of the pull request if you want to require additional verification. If have done something similar with auto accepting docs-only pull requests in the past.
  - asciimike 5y ago
    Dependabot PM here: We've provided an action that will provide metadata (e.g. semver bump) that you can use to enable granular automerge. See https://github.com/dependabot/fetch-metadata/#enabling-auto-merge https://github.com/dependabot/fetch-metadata/#enabling-auto-... for an example.

skybrian 5y ago

This seems like good motivation to prune your dependencies if they’re getting out of hand. Of course, easier said than done, but at an ecosystem level maybe it will help?

mukesh610 5y ago
Well angular repositories tend to have tons of dependencies.
tailspin2019 5y ago
In the case of NPM, the only way to not have your dependencies be “out of hand”, is to not use NPM. /s (but also, for realsies)

rudian 5y ago

Disable it. If you don’t want to, limit it to weekly or monthly. I agree that Dependabot is super noisy especially by default.

whymarrh 5y ago
Yup, there's quite a few different configuration options available: https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates https://docs.github.com/en/code-security/supply-chain-securi...

koblas 5y ago

The "biggest" problem in the JavaScript ecosystem (NPM) is that dependadabot doesn't know how to discriminate between dependancies and devDepandancies. I don't really care if jest includes a package that has a regex issue. It's not production code. I do care if babel introduces a backdoor, but somehow they're treated with equal importance.

leftshift 5y ago
It depends, attacks via build pipelines can be devastating.
- tailspin2019 5y ago
  Yep. Unfortunately it’s not clear cut that we don’t have to worry about devDependencies vulnerabilities.
greysteil 5y ago
PM for security products at GitHub here. Totally agree. The good news is that I think GitHub is in a position to fix this - expect progress in the next 12 months. One change that's needed here is data for each vulnerability on whether it's ever relevant in development. The advisory database that powers GitHub's security alerts (and npm audit, and NuGet audit) now has a dedicated curation team and is ready to curate more ecosystems and more information. That data then needs to be hooked up with GitHub's security alerting logic. That shouldn't be too difficult - we already detect whether a dependency is used in development or production, and the team here is growing. Finally, for this to work we'd need a new UI concept for vulnerabilities you aren't affected by. We're already working on functionality with a very similar requirement (one that tells you whether you're using the vulnerable function within a dependency). I can't make promises, but I can say that GitHub has an increasing amount of energy. Expect progress :-)

greysteil 5y ago

PM for security products at GitHub here (and one of the original authors of Dependabot). Sorry to hear that. I wouldn't expect us to be telling you about 1-5 security issues a day - do you maybe have (non-security) version updates enabled? If so and they feel like spam to you I'd recommend turning them off. (I wish I had a better suggestion, but until Dependabot supports grouped updates it sounds like it just isn't right for you.) Dependabot doesn't support grouped updates yet but we hear the feedback and the team wants to work on them. Most of the investment in Dependabot recently gone towards improving our infrastructure and improving the experience for security updates. The team is still relatively small (it's 7 people), and supporting a service like this at GitHub scale is hard, but we're keen to keep improving.

plasma 5y ago
HN is great, can I chime in with some feedback too, for NuGet I’m seeing Dependabot open separate PRs for the same dependency that’s out of date in the one repo that has multiple projects that relate to each other (they reference one another in csproj files). They thus also need to be updated together, but I wish one PR was opened to update the dependencies in all projects at once, instead of multiple PRs I to merge. PS: I think you should highlight dependabot updates on the Security tab in GitHub repo, I thought it was on before (but was actually just the security notices) because dependabot itself is hidden away in Insights -> Dependency graph -> Dependabot which was a bit surprising.
- greysteil 5y ago
  Feature requests always welcome! I'll pass it on to the Dependabot team.
  - plasma 5y ago
    Thank you
    - asciimike 5y ago
      Let me know if https://github.com/github/roadmap/issues/148 https://github.com/github/roadmap/issues/148 is in the right spirit of what you're aiming for. I think that what will get implemented will be a bit broader (covering version updates and security updates) and will allow for grouping by manifest, language, vulnerability, and potentially arbitrary labeling in the config file.

staticassertion 5y ago

It seems to primarily be a frontend thing. I get tons and tons of them, it's really annoying.

hiq 5y ago

I also get a lot of spam from dependabot because of prereleases, I wish they would fix this bug: https://github.com/dependabot/dependabot-core/issues/2547 https://github.com/dependabot/dependabot-core/issues/2547 As others have pointed out, you can opt for daily / weekly or monthly updates, I'll stick to monthly until they fix this bug.

greysteil 5y ago
Hmmm, it's been a long time since I worked on Dependabot Core, but I think I can fix that one - we just need to special case `native-mt` as a version type (as opposed to applying standard Maven version comparison rules on it). I'll try and get a PR in today and will tag you. Update: https://github.com/dependabot/dependabot-core/pull/4077 https://github.com/dependabot/dependabot-core/pull/4077

boarnoah 5y ago

I usually ignore those and bundle a bunch in a single PR. The worst I found was another team which merges in depandabot PR's one by one. Their git history isn't pleasant to look through :(

karlding 5y ago
The git log command has a --perl-regexp flag [0], which allows you to filter commits that match a Perl-style regular expression. I guess in that situation you could specify a regular expression that excludes dependabot in --author. If typing --perl-regexp gets old, you can always alias it or add a repo/global config option via grep.patternType [1]. Or you can create an alias for adding the less-powerful --invert-grep [2]. [0] https://git-scm.com/docs/git-log/2.32.0#Documentation/git-log.txt---perl-regexp https://git-scm.com/docs/git-log/2.32.0#Documentation/git-lo... [1] https://git-scm.com/docs/git-config/2.32.0#Documentation/git-config.txt-greppatternType https://git-scm.com/docs/git-config/2.32.0#Documentation/git... [2] https://git-scm.com/docs/git-log/2.32.0#Documentation/git-log.txt---invert-grep https://git-scm.com/docs/git-log/2.32.0#Documentation/git-lo...

X6S1x6Okd1st 5y ago

Yup, my PR review requested page is near useless because of all of the dependabot PRs.

skipants 5y ago

A setting I turned on to make it more manageable is to ignore patch updates and have dependabot only make PRs for major & minor version bumps.

hakre 5y ago

it was easy: block the user. then it got harder: create one branch that blocked the dependabot branch. then it got harder again: create 00 00 00 - FF FF FF branches (let it run with parallelism and over night). github support is not helpful on this.

pabs3 5y ago

Not recording exact dependency versions seems like the right way to stop those PRs from happening.

asciimike 5y ago

Dependabot PM following up a few days late > Is there an option to tell dependabot "make one PR per week at most ... You can set the `open-pull-requests-limit: 1` (https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates#open-pull-requests-limit https://docs.github.com/en/code-security/supply-chain-securi...) and the `schedule.interval: weekly` to limit the number of created PRs to one per week > ... and bundle your changes"? We've referred to this feature as "grouped updates" and it's tracked on the roadmap: https://github.com/github/roadmap/issues/148 https://github.com/github/roadmap/issues/148 Potentially using `allow: direct` (https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates#allow https://docs.github.com/en/code-security/supply-chain-securi...) to ignore the random sub dependencies, or ignoring minor versions (https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates#ignore https://docs.github.com/en/code-security/supply-chain-securi...) of some/all dependencies might help reduce that noise.