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

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

なるほどね。Rust/Cargo版のgovulncheckみたいなやつを探してみるよ。あと、geomys/sandboxed-stepっていうアクションのアイデアはすごくいいと思うんだけど、公式のactions/*以外を使うのにはちょっと抵抗があるんだよね。とりあえず中身をチェックしてみるよ。ツールボックスに入れておくと便利そうだし。

GovulncheckはGoエコシステムの中でも最高レベルの機能だよ。これがあるのは本当に大きい！脆弱な関数呼び出しを追加するようなPRが出たときに警告を出すGitHubアクションを作ったんだけど、脆弱な呼び出しだけをピンポイントで直すっていうアドバイスと相性がいいと思うよ。https://github.com/imjasonh/govulncheck-action GHAでそのままツールを走らせるのもいいけど、PRにアノテーションやコメントを直接書き込んでくれる機能が気に入ってるんだ。ちなみに、そのリポジトリはDependabotでPRの自動マージを有効にしてる。JSのコードベースならこれが最強だと思う。

クライアント側のコードでしか使ってないNPMパッケージに対して、DependabotからReDoSの警告が来る数が多すぎて本当に参るよ。バックエンドで動いているかどうかに応じて警告するか判断してくれるような仕組みが欲しいな。クライアント側のReDoSなんてこっちには全く関係ないんだから。

JSのエコシステムにも同じようなツールってあるのかな？もしないなら、クールダウン期間を置いてからDependabotで自動更新させるのが今のところはベターな選択肢かも。自動化しておかないと、結局ずっと依存関係を放置することになっちゃいそうだし。

うちはモダンなDependabot的なエージェント（あるいは連携ツール）のfossabotを作ったよ。アプリのコードを解析して、依存関係がどう使われているかを把握した上で、アップグレードごとに安全か要レビューかを判断したり、安全なアップグレードをまとめて戦略的にバージョンを上げたりしてくれるんだ。エージェントが文脈をしっかり理解しているから、破壊的な変更への対応も可能だよ。https://fossa.com/products/fossabot/ この用途向けに設計された独自の静的解析エンジンを使っていて、JS/TSの解析精度には自信があるよ。毎月無料枠もあるし、次はどの言語のエコシステムに対応すべきかフィードバックが欲しいな…JavaとかPythonかな？govulncheckみたいな静的解析がこの問題解決の隠し玉だって著者には完全に同意するよ！動的言語は本当に扱いが難しいからね。あと、自分たちでブログにも書いたけど、すごくイケてる評価用フレームワークもあるよ。

Dependabotは、リポジトリのコントリビューター権限がある時に見られるタブの一つになってくれればいいのにと思う。メール通知はうざいし、ほとんどフィルターしちゃってるけど、古いPRが溜まりっぱなしになるのも嫌なんだよね。便利ではあるんだけど、複数のリポジトリにまたがってこういうタスクを数時間で片付けたい時だけ使えるようにしてほしい。

自分はDependabotをすごく便利だと思ってるよ。まあ、イライラさせられることもあるけど、そのおかげで依存関係を最小限に抑えることの大切さを思い出させてくれるからね。

かなり的を射たアドバイスだと思う。自分は定期的な依存関係のアップデート（APIの変更点や、アップストリームの意図しないsemverの破壊などを把握するのに便利）にDependabotを活用してるけど、その組み込みの脆弱性スキャンに関しては、各エコシステムが持っている標準的な解決策の方が圧倒的に優れているよ。

依存関係の更新は、各ライブラリ側のサイクルに合わせるのではなく、開発サイクルに合わせて行うべきだ。例えば、各依存ライブラリの更新タイミングではなく、リリースの開発サイクルを始める時にまとめてアップデートするほうがいい

まさにその領域で取り組んでるけど、自分たちのアプローチはDependabotを置き換えるのではなく、補完することだった。自分たちのアプリ（https://www.infield.ai ）は、依存関係管理の中でもプロジェクト管理やチーム間の連携に焦点を当ててる。アップデート作業を3つのレーンに分けていて、a) 既知の脆弱性に対応するための個別のアップデート（リアクティブなもので、ほとんどはDependabotが対応）、b) 陳腐化や放棄されたライブラリによる中優先度のアップデート、c) RailsやDjangoのアップグレードのように数ヶ月かかるフレームワークのアップグレード、という感じだね。自分たちのソフトウェアを使えば、これら各カテゴリの優先順位付けや作業記録、libyearの推移をトラッキングして、メンテナンスのローテーションを管理できるよ。

カスタムGithub Actionsを使う方法はすごくカスタマイズ性が高くて柔軟だね。理論上は自動承認の設定だって作れるし。

もっと構造化されたものがいいなら、自分も触っているRenovate（特に関係者じゃないよ）をおすすめする。Renovateの方が対応しているエコシステムもずっと多いし、コミュニティも充実していてカスタマイズも効くからね。

実際に使ってみると、デフォルトツールであるDependabotがこれほどまでにイマイチだったのかと驚くよ。マルチステージのdockerfileみたいな単純なものすら、ずっと前からDockerにある機能なのに、Dependabotではいまだに何の通知もなくサポート外なんだから！