HN🔥 212
💬 64

【GitHub】Dependabotの通知がうるさい?完全にオフにする方法

todsacerdoti
約9時間前

ディスカッション (11件)

0
todsacerdotiOP🔥 212
約9時間前

GitHubのDependabotを無効化(オフ)にする方法についてのトピックです。プルリクエストが多すぎて開発のノイズになっている場合や、別の依存関係管理ツールを利用している場合に、リポジトリの設定から簡単に停止する手順についてまとめられています。

1
samhclark
約9時間前

This makes sense to me. I guess I'll start hunting for the equivalent of govulncheck for Rust/Cargo.

Separately, I love the idea of the geomys/sandboxed-step action, but I've got such an aversion to use anyone else's actions, besides the first-party actions/* ones. I'll give sandboxed-step a look, sounds like it would be a nice thing to keep in my toolbox.

2
ImJasonH
約9時間前

Govulncheck is one of the Go ecosystem's best features, and that's saying something!

I made a GitHub action that alerts if a PR adds a vulnerable call, which I think pairs nicely with the advice to only actually fix vulnerable calls.

https://github.com/imjasonh/govulncheck-action (https://github.com/imjasonh/govulncheck-action)

You can also just run the stock tool in your GHA, but I liked being able to get annotations and comments in the PR.

Incidentally, the repo has dependabot enabled with auto-merge for those PRs, which is IMO the best you can do for JS codebases.

3
nfm
約8時間前

The number of ReDoS vulnerabilities we see in Dependabot alerts for NPM packages we’re only using in client code is absurd. I’d love a fix for this that was aware of whether the package is running on our backend or not. Client side ReDoS is not relevant to us at all.

4
mehagar
約8時間前

Is there an equivalent for the JS ecosystem? If not, having Dependabot update dependencies automatically after a cooldown still seems like a better alernative, since you are likely to never update dependencies at all if it's not automatic.

5
robszumski
約8時間前

We’ve built a modern dependabot (or works with it) agent: fossabot analyzes your app code to know how you use your dependencies then delivers a custom safe/needs review verdict per upgrade or packages groups of safe upgrades together to make more strategic jumps. We can also fix breaking changes because the agents context is so complete.

https://fossa.com/products/fossabot/ (https://fossa.com/products/fossabot/)

We have some of the best JS/TS analysis out there based on a custom static analysis engine designed for this use-case. You get free credits each month and we’d love feedback on which ecosystems are next…Java, Python?

Totally agree with the author that static analysis like govulncheck is the secret weapon to success with this problem! Dynamic languages are just much harder.

We have a really cool eval framework as well that we’ve blogged about.

6
tracker1
約8時間前

I kind of wish Dependabot was just another tab you can see when you have contributor access for a repository. The emails are annoying and I mostly filter, but I also don't want a bunch of stale PRs sitting around either... I mean it's useful, but would prefer if it was limited to just the instances where I want to work on these kinds of issues for a couple hours across a few repositories.

7
apitman
約7時間前

I find dependabot very useful. It's drives me insane and reminds me of the importance of keeping dependencies to an absolute minimum.

8
woodruffw
約7時間前

I think this is pretty good advice. I find Dependabot useful for managing scheduled dependency bumps (which in turn is useful for sussing out API changes, including unintended semver breakages from upstreams), but Dependabot’s built-in vulnerability scanning is strictly worse than just about every ecosystem’s own built-in solution.

9
aswihart
約6時間前

Dependencies should be updated according to your development cycle, not the cycle of each of your dependencies. For example you might want to update dependencies all at once when you begin a release development cycle, as opposed to when each dependency completes theirs.

We're in this space and our approach was to supplement Dependabot rather than replace it. Our app (https://www.infield.ai (https://www.infield.ai)) focuses more on the project management and team coordination aspect of dependency management. We break upgrade work down into three swim lanes: a) individual upgrades that are required in order to address a known security vulnerability (reactive, most addressed by Dependabot) b) medium-priority upgrades due to staleness or abandonedness, and c) framework upgrades that may take several months to complete, like upgrading Rails or Django. Our software helps you prioritize the work in each of these buckets, record what work has been done, and track your libyear over time so you can manage your maintenance rotation.

10
operator-name
約6時間前

The custom Github Actions approach is very customisable and flexible. In theory you could make and even auto approve bumps.

If you want something more structured, I’ve been playing with and can recommend Renovate (no affiliation). Renovate supports far more ecosystems, has a better community and customisation.

Having tried it I can’t believe how relatively poor Dependabot, the default tool is something we put up with by default. Take something simple like multi layer dockerfiles. This has been a docker features for a while now, yet it’s still silently unsupported by dependabot!