scalafixを使ってclass名とfile名が異なっているものを自動修正したり警告を出す

というのを作ったので貼っておきます。 細かいところが雑ですが・・・。

Javaだとpublicなclassだと強制的に揃えないといけないですが、良くも悪くもScalaだと自由なので、揃えたい場合には、わざわざこういうのを作らないといけなくて不便。

file名ではなく、class名の方を合わせることによって修正したい場合もありえるでしょうけど、とりあえずfile名強制変更にしてあります。

TODO: packageとdirectory構造の検知と強制移動もやりたい。

gist.github.com

scala-stewardの使い方や動かし方の方法一覧

今までいくつかblog書いたが、どういうときに、どの方法使えば良いのか?が明らかにわかりにくいと思ったので、現状のまとめ

あと

https://tarao.hatenablog.com/entry/scala-renovate

scala-stewardを自分でホストするのは面倒だし, かと言ってGitHub Actionsで動くようにするのもそれなりに面倒なようです.

とあり、たしかにそうなんですが、べつに自分でホストしたり、自分でGitHub Actionsで動かす必要ないことも多々あるよ、という話 (とはいえ現状はpublic repoに限るか・・・?)

現状自分が思いつく方法一覧

  1. 公式のrepos.mdにpull reqして自分のリポジトリを記載してもらう
  2. 公式のGitHub Appsを使う(まだbeta版・・・?)
  3. 自分で完全にホスト(GitHub Appsではなく、普通のアカウント使う)
  4. GitHub Actions使う(デフォルトの secrets.GITHUB_TOKEN 使う)
  5. 独自にGitHub Apps作って使う

細かいバリエーション含めたり、今後のこと考えると、他の方法というか微妙に解説してない部分も多々出てきそうだけど、一旦上記の5種類で。

以下、前提条件や、メリット、デメリットなどを解説

1. 公式のrepos.mdにpull reqして自分のリポジトリを記載してもらう

  • 現状では、一番デファクトな方法、のはず
  • OSSである必要がある?(private repoの場合は3, 4, 5のどれかになるはず?)
  • 良くも悪くも、勝手に必ず実質最新版のscala-stewardが使われる
  • 実行タイミングはわりと速い(設定によって制御も可能)。しかし、ライブラリリリース後から、pull reqがくるまで、数十分から最大1〜2時間遅れる場合がある気もする?ので、その時間すら許容出来ない、完全に任意のタイミングで実行したいなら少し不便?
  • (一度追加したら変わらないならほぼ気にする必要ないが) 対象リポジトリの追加、変更、削除の場合に、repos.mdにpull reqする(そしてmergeしてもらう)のがほんの少し面倒?
  • あとそのrepos.mdの権限チェックが実質手動のはずなので、(原理上、他人のを追加削除出来る可能性があって)気持ち悪い

2. 公式のGitHub Appsを使う

3. 自分で完全にホスト(GitHub Appsではなく、普通のアカウント使う)

  • private repoも可能
  • 例えば以下のようなの(CircleCIのcronで動かす例)
  • https://creators-note.chatwork.com/entry/2020/10/05/180208
  • どこで動かすのか?によるが、独自に色々やる手間やコストはかかる
  • やり方によるが、repos.mdが自分たちの好きなところで管理できるので、わざわざ公式にpull reqする必要がない
  • (なんならscala-steward自体のコード改変含めて)動かし方やタイミングその他色々が自由にできる
  • (独自にビルドしない限り) maven centralなどにあるものを使うならば、少し古いscala-stewardになってしまう
    • もちろん独自に最新をビルドしてもいいが、引数の指定方法に互換がなくなった場合が面倒
  • GitHub Appsではなく、bot用のアカウント(普通に人間用に作るものと同一)のやつだと、色々不便や問題点がなくはない
    • GitHubの規約では、そういうアカウントは、一人一つまで、と定められている(無制限に作ったら怒られるはずだぞ!scala-steward動かすだけなら、無制限には必要ないが)
    • そういうアカウントを複数人でいい感じに管理する方法がないはず(だから本来そういう用途にはできればGitHub Apps使え、ということになるはず?)
    • よって、この点においては、個人的には5のGitHub Apps作る方法のほうがオススメではある
  • この方法は、アカウントさえ用意できれば、公式のGitHub Actions使えば、secretの設定と、yamlファイルと、(必要なら)repos.mdを置くだけで動くので、そんなに面倒ではないはず
  • また、chatworkさんの記事もCircleCIのcronだが、最近のCIは大抵はこういうcron機能があるはずなので、完全独自にserver用意したりする必要はないはず

4. GitHub Actions使う(デフォルトの secrets.GITHUB_TOKEN 使う)

  • private repoも可能
  • これ
  • https://xuwei-k.hatenablog.com/entry/2020/10/17/005726
  • 本当にyaml 1つ置くだけなので、手順自体はある意味一番簡単だが・・・
  • 色々上記blogに追記したとおり「他のGitHub Actionsが動かない」ので「他のCIとGitHub Actionsを併用」「pull req来たのにCI動かないのを許容」という、微妙な構成になるので、そんなに使い勝手良くない

5 独自にGitHub Apps作って使う

  • private repoも可能
  • これ https://xuwei-k.hatenablog.com/entry/2020/11/21/035306
  • blogではGitHub Actions前提で書いたが、べつにほかのCIでも原理上動かせる、はず(試してない)
    • つまり、他のCI上からでも、GitHubAPI呼び出したり、GitHub Appsからtoken生成は出来るはず
  • 3に書いた、(普通の人間用と同じ種類の)アカウントを用意して運用するデメリットは避けられる
  • つまり、GitHub Appsは気軽に作って良いはず。また、管理もorganizationに紐付けられて便利
  • だた、若干最初の手順は、(他に比べて一番?)面倒ではある?が、organization単位で1つ作るだけなら、(特にprivate repo用に作るなら)、そんなに何度も必要な手順ではないので、全然許容範囲ではあると思う
  • 独自に運用するにあたって、(独自にビルドしない限り)最新版が使えない、などのデメリットは、3などと同様

scala-stewardを独自に作ったGitHub App(bot)で動かす方法

というわけで、デフォルトの GITHUB_TOKEN 使う方法以外を模索している最中のメモ。

多少参考にしたblog

sue445.hatenablog.com

続きを読む

今までありがとうTravis CI、さよならTravis CI

しっかり調査してないですが、こういったCIサービスがほぼ存在しない時期にほぼほぼ最初に登場して、一時期明らかにデファクトスタンダードだったと思うので、昔からOSS活動している人ほど、とても多く利用してお世話になっていたと思うので、そういう人であればあるほど、この状況は、怒りではなく、悲しいというか残念というか、辛いと思うんですよね・・・。

続きを読む

2020年11月現在のScala 3(Dotty)とScala 2のコンパイル速度比較

最初に結論

Scala 2.13.33.0.0-M2-bin-20201031-1ab76c1-NIGHTLY をscalaz最新版でベンチマークしたところ、

Scala 2.13.3は平均約57秒Scala 3の最新版は平均約31秒

約45%短縮!!!

めでたいなぁ。 他の条件で計測した場合にどうなるのかわからないが、このままの速度を維持して欲しい。

以下詳細な条件や結果記載。

続きを読む

sbtのremote cacheのidにcommitの日付を入れる

という小ネタ。

sbt 1.4.1時点のデフォルトでは、単にgitのcommitのhashのみだが、日付が入っていたほうが、例えばローカルのキャッシュを手動で削除したりする際などに便利そうなので。

https://github.com/sbt/sbt/blob/4a2aaabb9b41a9e016e/main/src/main/scala/sbt/internal/RemoteCache.scala#L32-L41

ただ、以下のように、近いうちにgitのhashではなく、ソースコードの変更を検知してキャッシュをより賢くやる仕組みが入る可能性があるので、それがすごくうまく動くなら、このコード必要なくなる可能性はありますが・・・

github.com

gist.github.com