上限と同時実行数

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

著者 Daniel Zoghalchali·Latchkey

数値#

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

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

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

カスタムランナー構成#

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

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

知っておくとよいこと#

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