いけむランド

はてダからやってきました

dependabot おじさんの憂鬱

dependabot と付き合ってるソフトウェアエンジニアの方はたくさんいると思いますが、なんかぐぐっても gem の例しか出てこなくて、gradle で使ってる人はいないのかと不安になったため、ちょっと普段やってることをまとめておきます。

gem 版は程よい記事がまとまっているため、基本的にこれの中で Java (gradle) の場合に自分はこうやってるよという部分を挙げていきたいと思います。

zenn.dev

まずは PR の description に changelog と commit diff へのリンクが記載されていることが多いため、それを見ます。

API breaking-change があった場合はそもそもコンパイルできないため、そこまですべてを神経質に見る必要はないですが、そのライブラリの使用目的部分に差分がある場合は特に気にかける必要があります。(たとえば、ログライブラリだったらログのフォーマットに関する部分とか。)

また、リポジトリの最新の issue を確認し、適用しようとしているバージョンにバグが出ていないかも同様に必要です。(自分はうっかりここの確認を漏らしてしまい、バグのある最新バージョンをマージしてしまったことがあります。)

gradle ではロックファイル的なものはまだメジャーではないっぽいため、バージョンをロックしたい場合は build.gradle にきちんとバージョン指定でライブラリを記載し、.github/dependabot.yml で ignore 設定するのが良いでしょう。

blog.64p.org

docs.github.com

もちろん PR の CI が pass していることは必須ですし、デプロイ後の E2E シナリオテスト も pass することを確認できるならしておきましょう。単体テストや統合テストで発見できない仕様変更を踏むこともあります。(実際に踏んだ例↓)

fd0.hatenablog.jp

PR のレビュー & マージ自体は上記のことをしておけば、一人で問題ないと思いますが、追加でコード修正が必要なパターン (pmd に怒られるなど) は別の人にお願いすることになるでしょう。