sbtのprojectでpull requestで変更された依存ライブラリの一覧を出す

少し前に、以下のようなものを作りましたが

xuwei-k.hatenablog.com

github.com

それと似たような発想で

「このpull reqで変わったライブラリは何か?」

のdiffを出す仕組みを作りました、という話。

ここでのポイントは

「間接的に依存してるjarも含むdiff」

も出す、というもの。

既に似たようなものは存在していても全然不思議ではない気がするけど、調べるより作った方が速いので作りました。

続きを読む

CIで増減した警告を教えてくれるsbt pluginを作りたい話

モチベーションなど

  • 自分が知る限り、sbt使ったbuildで、CIで増えた(あるいは減った)警告を出してくれる簡単な仕組みは存在しない
    • もし知っていたら、作る必要なくなるので教えてください
  • reviewdogは使ってる https://github.com/reviewdog/reviewdog
  • reviewdogは素晴らしいが、細かい問題がある?
    • (少なくともデフォルトでは?) コード変更した部分の警告しかコメントしてくれなくない?
    • 実は全ての警告を記録してくれる機能あるのだろうか・・・?あったら教えてください
      • とはいえ単に全てを毎回教えてもらっても困るので、あくまで「そのpull reqで増減したもの」だけ知りたい
  • コード変更した部分の警告 だとなぜ困るか?
    • 例: sealed traitの子供を増やした時に、matchの網羅性の警告が増えるのは、全然別のところである場合が多々。
    • あるいは、コンパイラオプション変えた時に増減する警告を知りたい
    • あるいは依存ライブラリ更新
    • あくまで一例で「変更した場所と、警告が増える場所」が違うことはよくある、はず
    • それに気がつかないままmergeする危険がある
    • 警告を全部雑に表示するとか、[warn] の行数判断、みたいな雑な方法もなくもないが・・・
  • "-Wconf:msg=match may not be exhaustive:error" のようなコンパイルオプションでエラーにしてしまう方法
    • https://eed3si9n.com/ja/stricter-scala-with-xlint-xfatal-warnings-and-scalafix/
    • 警告の種類によってはありだが、あくまでも警告は警告なので、あまり深刻ではないものまでエラーにしたくない
    • 複数のScala versionでのcross buildの都合やその他で、どうしても多少警告は出る場合もある。警告をゼロにするために多大なコストを割くのは避けたい
    • あまり警告避けるために変な場当たり的なコード書かれたり、(問題があるコードなのにアノテーションなどで)雑な抑制をされて、それが忘れられたままになるくらいなら、警告出たままの方がいい(しかし警告がその時点で増えたことはできるだけ認識したい)

作成方針

  • まずmainのbranchへのpushのCIで、全ての警告を記録してファイルに書き出し、どこかにuploadしておく
    • github actionsなら actions/upload-artifact@v3 使って
  • pull_requestのCIでは
    • まず全ての警告を同じ形式で出す
    • default branchの前回の最新の警告一覧を記録したファイルをdownloadしてくる
    • 前回と今回のを比較してdiffを出す
      • このdiffの出し方がよく考えたら難しい、助けて
    • diffをgithub actionsで雑にコメントする

作っている最中のものがこれ https://github.com/xuwei-k/sbt-warnings-test

今後やること、悩みどころ

  • まだpublishすらしていない、あくまでtest repoで、本体のrepositoryすら作ってない リリースした https://github.com/xuwei-k/sbt-warning-diff
    • githubが絡むので、テストが難しいので
    • 本格的に運用してみないと細かい使い勝手や問題点がわからないので
  • 細かい問題見つかるたびにpublishし直すのもだるいので、ある程度完成してからpublishする?
  • GitHub Actions前提で作るか、どうするか?
    • 今はsbt plugin自体は汎用的に、任意のCIから使えるように、ファイル書き出しと読み出しまでしか行なっていない
    • その後の、upload, download, pull reqへcommentなどは、普通のgithub actions任せ
    • 独自GitHub Actions(typescriptで作る?)?か、sbt plugin内部からgithubAPIを直接呼ぶか、どうするか・・・?
  • 雑にjsonをコメントするのではなく、インラインでいい感じにコメントするなどしたい

sbtの独自Configurationを使ったbuild速度の改善

突然ですが、皆さんsbtのchrome trace吐き出す機能使ってますか?大抵の人は使ってないというか、存在すら知らないと思います。

https://github.com/sbt/sbt/pull/4576

以前以下のあたりでも多少話を出しました

https://xuwei-k.hatenablog.com/entry/2022/03/30/142529

さて、それを使ってsbtのbuildのsub project毎のcompile速度を眺めて、頭の中でDAGを描いてみたときに、稀に、

続きを読む