箇条書きで書いていきます。
公式ドキュメント
大前提
- パブリックリポジトリでは使う意義はほぼ無いと思います
- パブリックリポジトリは GitHub謹製 のランナーの時間制限がないから
- セルフホストのランナーにはセキュリティ上の懸念が生じる可能性があるから
- つまり、以下の内容は全てプライベートリポジトリで利用することが前提となります
インストールについて
- 出てきたスクリプトをコピペして実行するだけなのですぐにできる
- arm64 にも対応しているほか、Windows や Mac にも対応している
実行について
- 永続的に実行指定ならば
nohup ./run.sh &
とかしたほうがいい- 止める際には
bin/Runner.Listener run
のプロセスを止める
- 止める際には
- 複数台ランナーを立てればそれだけ並列実行ができる
- GitHub謹製ランナーだと並行数は(確か)3
- ワークフローの YAML の中の
runs-on:
に、インストールする際に命名した「タグ」を指定することで実行するランナーを振り分けられる- インストールマシンごとの特性に合わせて振り分けられる
良さそうなところ
- 属人化がしなさそう
- self-hosted 自体ではいじるところはなにもない
- workflow の YAML だけに集中できる
- Jenkins の苦労はない
- ランナーがインターネットから見える必要はない
- ランナー側から GitHub につなげてトンネル作っている(はず)から
- 必要に応じて起こしたり寝かしたりできる
- 家でラズパイ買って置いとけばいい気がする
- あるいは安心定額のVPS
- 並列数を 4 以上にしたい場合にはバカバカ立てるとGitHubホストランナーに勝てる
- あくまで並列数についての話
注意したほうがいいところ
- ランナー専用のマシンを用意すべき
- マシングローバルにインストールしたものは「掃除」ができないで永続的に残る
- 依存が生じてしまう可能性がある
- OS のパッケージやE2Eテスト用のブラウザのインストールで問題になる
- マシングローバルにインストールしたものは「掃除」ができないで永続的に残る
- GitHub謹製のホストランナーが落ちていたからといって、これで保険になるわけではない(はず)
- GitHub Actionsというシステムが落ちていたら意味がない
- ただしホストランナー「だけ」が落ちている場合にはこれで救われるかもしれない(推測)
- 「ホストのインストールコマンドを実行したときのユーザがコマンドの実行ユーザになる」ので sudo などの権限に注意する
- 環境汚染を考慮すると専用ユーザを作るのは必須
- そして専用マシンにすべき
- sudoersでパスワードいらずの専用ユーザを作って対応
- しかしpublicリポジトリで他人にSSHに入られたら死ぬ
- 結論としては sudoers しないほうがいいと思う
- グローバルインストールでアーキテクチャ依存のライブラリがあるとハマる
- たとえば
deb [arch=amd64] https://packages.microsoft.com/repos/edge stable main
- 上記は arm64 は提供されていない
- 提供されていたとしても、OSを調べて if 文で分岐してインストールパッケージを分けるみたいなところまで掘る?
- たとえば
- 環境汚染を考慮すると専用ユーザを作るのは必須
結論
- APIを定期的に叩いたりバッチ処理をしたり単体コマンド実行をしたりするcronを走らせるのが現実的
- ナイトリービルドとかナイトリーテストとか
- Release Drafter とか PR Labeler とか
- そのジョブだけ self-hosted に分散する
- 時間が長いものについては時間消費を防ぐために有用