Self-hosted runner とは

GitHub Actions の動作マシンを自分のマシンで行うこと、あるいはそのマシンのことです。

docs.github.com

どのようなマシンを Self-hosted runner に使うか

Self-hosted runner としては以下の OS とアーキテクチャの組み合わせがあります。Linux のディストリビューションの違いや、macOS や Windows の細かなバージョンの違いを考慮すると、理論上の組み合わせ数はかなり多いです。

OS
- macOS
- Linux
- Windows
アーキテクチャ
- x64
- ARM64

gyazo.com

macOS を runner として用いる

今回 macOS を runner として用いてみました。macOS を用いる理由は iOS アプリのビルドのためです。GitHub Actions が用意していくれるマシンでも macOS は選択できるのですが、クレジット（課金対象時間）の消費が半端なく多いです。したがって、macOS が必要なところは Self-hosted してみよう、ということです。

マシンスペック

用いた macOS のマシンのスペックは以下のとおりです。

MacBook Pro
- 13-inch
- 2017
- Two Thunderbolt 3 ports
CPU
- 2.3 GHz デュアルコア Intel Core i5
グラフィックス
- Intel Iris Plus Graphics 640 1536MB
メモリ
- 8 GB 2133 MHz LPDDR3
SSD
- 128 GB

やったことの箇条書き

やったことの箇条書きです。runner に使うマシンという性質上、極力インストールはしない方針です*1。

ちょっとなぐり書きで見苦しいです。

OSクリーン再インストール
Xcode を App Store からインストール
Command Line Tools for Xcode 14.3 をインストール
- https://developer.apple.com/download/all/?q=xcode
Chrome, Firefox & Edge インストール
iTerm2 インストール
- これは好みで
Tailscale 入れる
- これは完全に自分の環境のため
Amphetamine インストール
- クラムシェルでバックグラウンドで動かし続けるために必要
- App Store よりダウンロード
- Amphetamine Enhancer も場合によっては必要かも*2
Node.js をオフィシャルから入れる
- 入れ方は色々あるが、これがいちばん無難と判断した
- https://nodejs.org/ja/download
クラムシェルで動作が継続することを確かめる
SSH できるようにする
- マシンは直接さわらないで済むようにする
Homebrew をインストールする
ruby-build インストール
- git clone をしてからインストールスクリプトを走らせる
- $ ruby-build --version が実行できれば OK
$ brew install libyaml
- 最近の Ruby のビルド用

注意点など

Ruby は自前で入れる
- ruby-build を入れて、$ ruby-build 3.2.2 ~/actions-runner/_work/_tool/Ruby/3.2.2/x64 する
- インストールが終わったら $ touch ~/actions-runner/_work/_tool/Ruby/3.2.2/x64.complete する
- 上記のようにしておくと GitHub Actions の ruby/setup-ruby でいつもどおりに使える
Node.js (Yarn) や pnpm は事前準備不要でいつもどおりで OK
キャッシュの保存場所には注意する
- 他のリポジトリや他の runner と混じってしまわないようにする
落ちたらすぐに SSH できて調べられるのが便利
runner が落ちていることの検出機構は必要
- 最長でタイムアウトが 1日とかなので、それまで Action が止まってしまっていることに気づけない
一つのディレクトリが一つの runner となる
一つの runner は特定のリポジトリのみで用いられる
以上より、一つのマシンにたくさんディレクトリを作ることで、複数のディレクトリに複数の（並行する）runner を作れる
- そのような構造上、ディレクトリ構成としては例えば以下のようにするといい
  - ~/runners/ORGANIZAION/REPOSITORY/runner_01
  - ~/runners/ORGANIZAION/REPOSITORY/runner_02
  - ~/runners/ORGANIZAION/REPOSITORY/runner_03
  - ~/runners/ORGANIZAION/REPOSITORY/runner_04
一つのリポジトリで並行して走らせるためには、複数の runner を作成する
runner の常駐は ./run.sh コマンドにより行われるが、プロセス管理のために pm2 を使うのがおすすめ
- $ pm2 start run.sh -x --name ORGANIAZTION_REPOSITORY_runner_01 などとする
- ログは ~/.pm2/logs 配下にある
他に必要なパッケージ等は出てくるが、たいていエラーメッセージが親切なので随時入れていけばいい
- ただし、マシングローバルに入れる場合には、影響範囲を一応意識する
runner の情報は、runner のディレクトリ直下の .runner に JSON 形式で書かれている

感想

けっこう大変だし、特に「使い捨て」ではないから、以前の状態が残ってしまわないか、マシングローバルに変なものを入れてしまわないか、と言った点に気をつけないといけない。

そうするとまずこういう考えが浮かぶ。「GitHub Actions を普通に使えばいいのでは…？」。そしてそれはたいてい正しい。

ではあえて Self-hosted にする理由は特殊な場合のみで、例えば以下のような場合かなと思う。

iOS アプリのビルドや Windows ネイティブアプリのビルドを行う場合
- これは「特殊」ではないかもしれない
CI で用いるデータが巨大な場合（たとえば数十GB ～数TBとか）
- これはローカルで持ってるデータを使わないといけない
CI で用いるデータの事前準備が特殊な場合
- 画像、音楽、特殊な社内データベースから持ってこないといけない、など
CI で特殊なソフトウェアを用いる場合
- 毎回 GitHub Actions のマシンにインストールをしていられない場合とか、外に出せないとか、インストール手順やハードウェア要件があるとか

上記以外の場合はたとえ無料分から足が出るとしても、GitHub Actions のマシンを使うほうがいいのではないかと思う。GitHub Actions を使うことそれ自体は手段であって、CI を実行したいというのが目的（さらにいえば、CI で実行する内容を実現することが目的）だから、手段はシンプルでフレキシブルな方がいい。