一言でいうとreviewdogの紹介をするだけなのですが、すごくタイミングよく罠にハマった?ので、それの暫定的な回避も書いておきます。
続きを読むsbtのprojectでpull requestで変更された依存ライブラリの一覧を出す
少し前に、以下のようなものを作りましたが
それと似たような発想で
「このpull reqで変わったライブラリは何か?」
のdiffを出す仕組みを作りました、という話。
ここでのポイントは
「間接的に依存してるjarも含むdiff」
も出す、というもの。
既に似たようなものは存在していても全然不思議ではない気がするけど、調べるより作った方が速いので作りました。
続きを読むsbtで特定のprojectを含めた依存project全体に対してtask実行する
昔似たような違うものを使ったことがありますが、違うものです
続きを読む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
使って
- github actionsなら
- pull_requestのCIでは
- まず全ての警告を同じ形式で出す
- default branchの前回の最新の警告一覧を記録したファイルをdownloadしてくる
- GitHub Actionsの場合、これ使ったらとりあえず簡単に出来た気がする
- https://github.com/dawidd6/action-download-artifact/tree/46b4ae883bf0726f594
- 前回と今回のを比較して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前提で作るか、どうするか?
- 雑に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を描いてみたときに、稀に、
続きを読む