少し前に、以下のようなものを作りましたが
それと似たような発想で
「このpull reqで変わったライブラリは何か？」
のdiffを出す仕組みを作りました、という話。
ここでのポイントは
「間接的に依存してるjarも含むdiff」
も出す、というもの。
既に似たようなものは存在していても全然不思議ではない気がするけど、調べるより作った方が速いので作りました。
間接的なものの衝突や依存の管理含めたsbt pluginや、それらをしっかりするための何かは色々ある気がしますが
(あまり詳しくない。こういうのとか？ https://github.com/cb372/sbt-explicit-dependencies https://github.com/scalacenter/sbt-version-policy )
(bazelなどの他のbuild toolだとなんか根本的に違うとかあるかも？)
詳しくないし、話逸れるので、ひとまず普通に(?)sbt使っている、とします。
「間接的に依存してるjarも含むdiff」
を出すことで
「ライブラリAは、実はライブラリBに依存していたのか？いや今回から依存するようになったのか？？？ライブラリBの新しいversion 2の依存が入ったら、よくないのでは？？？」
みたいなことに気がつけるようになる・・・はず。あるいは
「新しいversionのライブラリCは、今回からライブラリDに依存しなくなったのか。依存していたせいでライブラリDのversion 2が使われていたけど、これは逆にDのversionが下がるのでは？？？そもそも、しっかりDのversionを明示するようにしておくべきか？？？」
みたいな、ややこしいパターンなど。
そもそも、そういう不整合？を別の観点から防ぐ仕組みも可能なら導入したほうがいい気はするが、それはそれであったとしても、最終的に人間が判断もした方がいい場合もあるはずなので？ 万が一のトラブル時に、どのpull reqで、どういう依存の変更が入ったのか、後から見返しやすいように？という
雑にやるには、sbt pluginにする程度のコード量でもなかったので、一旦gist貼り付けておくだけにしておきますが、 以前の警告などと同様、GitHub Actionsだったら
- default branchへのpush eventで、どこかに保存しておく
- pull reqでは、それをdownloadしてきて、diffを出して、それをbotにコメントさせる、など
みたいな流れです。
細かい実装の選択肢は色々ありえますが
- 例ではmainしか出してないが、必要ならtest側も分けて出す？
- 全てのsub projectに対して出すか、最終的にデプロイされる単位などで出すか(共通化のためのcommon的なsub projectでは出さない)
- そもそもexternal-dependenciesではなく、internal含めたり、もっと色々な情報出すか？
- cross scala version全てで出すか？
とりあえず今のところ汎用化したsbt plugin作るつもりもないので、各自勝手に改造して使ってください・・・？でいいかな？
例えば、play-jsonの記述を 2.9.2 から 2.9.3 にした場合に、間接的な依存のjackson含めて、以下のように出てくれます
