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

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上からでも、GitHubのAPI呼び出したり、GitHub Appsからtoken生成は出来るはず
  • 3に書いた、(普通の人間用と同じ種類の)アカウントを用意して運用するデメリットは避けられる
  • つまり、GitHub Appsは気軽に作って良いはず。また、管理もorganizationに紐付けられて便利
  • だた、若干最初の手順は、(他に比べて一番？)面倒ではある？が、organization単位で1つ作るだけなら、(特にprivate repo用に作るなら)、そんなに何度も必要な手順ではないので、全然許容範囲ではあると思う
  • 独自に運用するにあたって、(独自にビルドしない限り)最新版が使えない、などのデメリットは、3などと同様