GitHub Acitons では Self-hosted runner を利用して、独自のビルド環境でワークフローを実行することができます。
企業内のプロキシサーバ配下のマシンでも利用できるので、
- CI のたびにソフトウェアのインストールをしなくてもよい*1
- 社外に出せないライブラリを利用したビルドが可能
- GItHub Actions Runner の使用制限を超えてビルドマシンのリソースを自前で用意できる
などのメリットがあります。仕事でも EC2 の Ubuntu AMI を使って Self-hosted runner を構築しています。
GitHub Actions の初期の頃から Self-hosted runner の機能は提供されていましたが、ユーザープロセスとして起動するため、ホストマシンに SSH 接続して runner.sh を起動する必要がありました。runner.sh & とかでバックグラウンドで起動するといつの間にかプロセスが死んでたりするし、tmux で起動して detouch しておくのも信頼性に乏しいし・・。Docker コンテナ化して常時起動している人のブログも発見しましたが Docker がらみの CI で DinD 問題が発生するし・・ということでターミナルを1つ専用に上げっぱなしにして使っていました*2。
runner.sh は標準出力にジョブの成功・失敗のログを出力するので Web UI 見なくても結果がわかります。セルフアップデート機能もあり、アイドリング時に自身のバージョンを自動的にアップデートしているようでした。
少し前にドキュメントを眺めてたら、Self-hosted runner をサービスとして登録できるようになっていました。
Mac / Windows / Linux いずれの runner でも登録可能で、それぞれ launchd / PowerShell / systemd を利用したサービス化が可能です。Mac では plist、Linux では serviced も利用可能なようです。
ドキュメントの手順通り Service 登録したところ、実行ユーザは従来通りの non-root ユーザ (Linux なら ubuntu ユーザ) なので、ワークフローやシェルスクリプトには変更不要でした。
Terminal で見ていたログも、Linux では journalctl を使って runner のログをウォッチできます*3。
$ sudo journalctl -u actions.runner.octo-org-octo-repo.runner01.service -f
これで Self-hosted runner の運用がかなり楽になりました。
