CI runner とは？パイプラインを実行するマシン
CI runner とは、実際にパイプラインを実行するコンピュートです。コードを checkout し、step を実行し、結果を CI サービスに報告します。
コードを push しても、CI サービス自体がテストを実行するわけではありません。CI サービスは各 job を runner - 実マシンや仮想マシン、またはコンテナ - に渡し、runner が作業を行います。runner を理解することが、CI の速度、コスト、信頼性を理解する鍵です。
runner が実際に行うこと
runner は CI サービスに登録し、job を待ち、その job を実行します。リポジトリを clone し、toolchain をセットアップし、各 step を順に実行し、artifact をアップロードし、終了ステータスを報告します。job が終わると、runner は自身を破棄するか、次の job を待つためにアイドル状態に戻ります。
runner とサービスのハンドシェイク
runner は認証された接続を通じて CI サービスに poll します。サービスは runner の label にマッチする job を割り当て、step の実行に合わせてログをストリーム返信し、結果を記録します。job の途中で接続が切れると、サービスが進行を確認できなくなるため、通常その job は失敗としてマークされます。
hosted、self-hosted、マネージド
- hosted: CI ベンダーがマシンを所有・運用します（例: GitHub-hosted runner）。セットアップ不要、分単位で課金。
- self-hosted: runner エージェントを自分のインフラで動かします。完全な制御、完全な運用負担。
- マネージド: サードパーティがあなたに代わって runner を運用します - ベンダー価格なしで hosted のような利便性。
なぜ runner がコストと速度を左右するのか
runner の CPU、メモリ、ディスクが job の実行速度を決めます。runner の価格と並列度が支払額を決めます。そして runner の信頼性 - クリーンな状態、健全なネットワーク、十分なメモリ - が build がどれだけ flaky になるかを決めます。CI の悩みの多くは、小さすぎる、遅すぎる、または汚れすぎた runner にたどり着きます。
Latchkey が果たす役割
Latchkey はマネージド runner プラットフォームです。GitHub Actions の job は Latchkey が運用する runner で実行され、通常 GitHub-hosted より約 70% 安く、warm pool から提供されるため cold start の待ちがなく、自己修復により一時的な障害は人手なしで retry されます。
重要なポイント
- CI runner とは、パイプラインの job を実行するマシンまたはコンテナです。
- runner は CI サービスに登録し、マッチした job を実行し、結果を報告します。
- 3 つのモデルは hosted、self-hosted、マネージドです。
- runner のサイズ、価格、クリーンさが CI の速度、コスト、flakiness を左右します。