上限と同時実行数

ジョブの実行時間の上限、同時実行数、アーキテクチャのサポート、ディスクサイズ、そしてプランごとのカスタムランナー構成の上限。

数値#

上限	値
最大ジョブ実行時間	ランナーあたり 4 時間。ジョブがまだ実行中でも 4 時間でマシンは終了されます
同時ジョブ	ワークスペースあたりデフォルトで 20 のビジーなランナー (アイドルのウォームランナーはカウントされません)。より高い上限も利用可能
オペレーティングシステム	Ubuntu 24.04 LTS のみ (Windows や macOS のランナーはありません)
アーキテクチャ	x86_64 (amd64) のみ。arm64 ホストランナーはありません (arm イメージは docker buildx でクロスビルド可能)
ディスク	100 GB (small、medium、large)、200 GB (xlarge)、カスタム構成では 100 から 500 GB
カスタムランナー構成	Launch: 2、Scale: 10、Enterprise: 無制限
リージョン	ランナーは AWS us-east-1 で実行されます

上限に達したときの対処#

これらの数値は、どれかが実際に効いてくる日にのみ問題になります。そうなったときにあなた側で変えること:

durationジョブが 4 時間に近づくジョブの途中でも 4 時間でマシンは終了するため、この上限は予算ではなく厳格な天井として扱ってください。作業を並列ジョブに分割する (各ジョブが独自のランナーを得ます) か、同じ作業をより早く終わらせるために 1 サイズ上げてください。

concurrencyピーク時にジョブがキューに入るデフォルトはワークスペースあたり 20 のビジーなランナーで、アイドルのウォームランナーはそれにカウントされません。上限を超えたジョブは、ビジーなランナーが終わるまでキューで待ちます。ピークが定期的にキューに入るなら、より高い上限が利用可能です。

platformWindows、macOS、または arm64 が必要それらの特定のジョブは GitHub ホステッドや他のランナーに留め、同じワークフロー内で自由に混在させてください。arm64 のコンテナイメージは docker buildx でクロスビルドします。QEMU はイメージに事前構成されています。

diskジョブがディスクを満杯にする自己修復はジョブの途中でディスクが満杯になるとキャッシュを削除しますが、ジョブが日常的にそのサイズの提供以上の容量を必要とするなら、恒久的な修正は最大 500 GB のカスタム構成です。

このうち 2 つには理由があります。4 時間の上限は、自己修復の再試行が請求額を膨らませないようにするのと同じセーフティネットです: ハングしたジョブがマシンや請求書を無期限に押さえられないことを保証します。そして同時実行の上限は ビジーな ランナーのみをカウントします。これは誤読しやすい点です: アイドルで待機しているウォームプールは 20 枠のどれも消費しないため、ウォーム容量が実際のジョブと競合することは決してありません。

カスタムランナー構成#

Latchkey Runners ページから、独自の latchkey-<name> ラベルを持つカスタム構成を作成し、CPU/メモリの形状とディスクサイズを選べます。AI Scan フローはワークフローを分析して適切な構成を提案します。そのイメージは自動でビルドされ、ランナーが使用可能になると通知されます。イメージビルドが完了するまで、そのラベルを狙ったジョブはキューで待機します。

カスタム形状がプリセットに勝る場合やそのコストを含む完全な判断ガイドは、AI Scan によるカスタムランナーにあります。

知っておくとよいこと#

ランナーは単回使用です: マシンあたり 1 ジョブで、その後破棄されます。ローカルディスクに書き込んだものはジョブが終わると消えます。永続化にはアーティファクトまたはキャッシュを使ってください。
GitHub ホステッドランナーのラベル (ubuntu-latest など) は並行して機能し続けます。一度に 1 ジョブずつ移行できます。
GPU、Windows、macOS、arm64 ホストが必要な場合は、当面それらの特定のジョブを GitHub ホステッドや他のランナーに留め、同じワークフロー内で自由に混在させてください。