コンテンツへスキップ
Latchkey ホーム
EnglishPortuguês日本語
無料で始める
ドキュメントメニュー
はじめに
  1. Latchkey とは
  2. Quickstart
  3. GitHub App をインストールする
  4. リポジトリの管理
ダッシュボードと分析
  1. ダッシュボードの概観
  2. コスト分析
  3. パイプラインのパフォーマンス
  4. 最適化インサイト
  5. Knowledge Base
  6. AI エージェントを接続
マネージドランナー
  1. ランナーの概要
  2. 最初のジョブを実行する
  3. GitHub ホステッドからの移行
  4. Latchkey CLI
  5. Runners ページ
  6. カスタムランナー (AI Scan)
  7. 自己修復
  8. ランナーイメージとソフトウェア
  9. プロビジョニングとウォームプール
  10. 上限と同時実行数
キャッシュ
  1. 依存関係のキャッシュ
  2. Docker レイヤーキャッシュ
チームと通知
  1. チームとロール
  2. 通知
  3. Slack 連携
請求とプラン
  1. プランとトライアル
  2. 請求の管理
  3. 使用量と無料分数
ヘルプ
  1. トラブルシューティング
  2. FAQ
  3. セキュリティアーキテクチャ
  4. セキュリティと権限
ワークフローファイル
  1. ワークフローファイル

上限と同時実行数

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

·Latchkey

要点

  1. Latchkey CI のジョブは timeout-minutes を最大 180 (デフォルトは 30) まで設定でき、CLI のジョブは最大 3 時間、Latchkey on GH のジョブは最大 4 時間 (4 時間の時点でまだ実行中なら最大 8 時間) 実行できます。ワークスペースあたり開始時点で 40 のビジーなランナーが同時実行可能。
  2. Linux x86_64 のみ: 現在 Windows、macOS、arm64、GPU ホストのランナーはありません。
  3. ランナーは単回使用です。出力はアーティファクトとキャッシュで永続化してください。

数値#

上限値
最大ジョブ実行時間ランナーあたり 4 時間。4 時間の時点でジョブがまだ実行中なら最大 8 時間
同時ジョブプランごとに設定: ワークスペースあたりのビジーなランナーは Developer 20、Launch 40、Scale 80、Enterprise は契約による (アイドルのウォームランナーとパーク済みランナーはカウントされません)。トライアルは Launch の数値で実行されます
支出上限デフォルトではなし。オーナーまたは管理者が Billing ページで米ドル単位で設定します。上限に達すると、Latchkey は新しいジョブを拒否し、キュー内のジョブを保留し、実行中のジョブを停止します。Latchkey ランナー上の GitHub Actions ジョブも対象です。暦月が変わるとリセットされます。
オペレーティングシステムUbuntu 24.04 LTS のみ (Windows や macOS のランナーはありません)
アーキテクチャx86_64 (amd64) のみ。arm64 ホストランナーはありません (arm イメージは docker buildx でクロスビルド可能)
ディスク100 GB (small、medium、large)、200 GB (xlarge)、カスタム構成では 100 から 500 GB
カスタムランナー構成Developer と Launch: 2、Scale: 10、Enterprise: 無制限
リージョンランナーは AWS us-east-1 で実行されます

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

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

durationジョブが 4 時間に近づくジョブは最大 4 時間 (4 時間の時点でまだ実行中なら最大 8 時間) 実行されるため、この上限は予算ではなく厳格な天井として扱ってください。作業を並列ジョブに分割する (各ジョブが独自のランナーを得ます) か、同じ作業をより早く終わらせるために 1 サイズ上げてください。
concurrencyピーク時にジョブがキューに入るワークスペースあたりのビジーなランナー数は各プランが定め (Developer 20、Launch 40、Scale 80。トライアルは Launch の数値で実行されます。Enterprise の上限は契約で定められます)、アイドルのウォームランナーとパーク済みランナーはそれにカウントされません。上限を超えたジョブは、ビジーなランナーが終わるまでキューで待ちます。ピークが定期的にキューに入るなら、ひとつ上のプランでこの数が上がります。
platformWindows、macOS、または arm64 が必要それらの特定のジョブは GitHub ホステッドや他のランナーに留め、同じワークフロー内で自由に混在させてください。arm64 のコンテナイメージは docker buildx でクロスビルドします。QEMU はイメージに事前構成されています。
diskジョブがディスクを満杯にする自己修復はジョブの途中でディスクが満杯になるとキャッシュを削除しますが、ジョブが日常的にそのサイズの提供以上の容量を必要とするなら、恒久的な修正は最大 500 GB のカスタム構成です。

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

カスタムランナー構成#

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

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

知っておくとよいこと#

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

4 時間です。4 時間の時点でジョブがまだ実行中なら最大 8 時間です。それ以上必要なジョブは、アーティファクト経由で処理を受け渡す複数のジョブに分割してください。上限に近づく単一ジョブは、たいてい並列実行できる処理を含んでいます。

同時に実行できるジョブ数は?

プランごとに決まります: ワークスペースあたりの同時ビジーランナーは Developer 20 台、Launch 40 台、Scale 80 台で、トライアルは Launch の数値で実行されます。Enterprise の上限は契約で定められます。あなたの上限で頻繁に待ちが発生する場合は、ひとつ上のプランで上限が上がります。

Latchkey ランナーは Windows、macOS、ARM に対応していますか?

現時点では対応していません。Latchkey ランナーは Linux x86_64 のみで、Windows、macOS、arm64、GPU ホストはありません。それらのジョブは GitHub ホスト型などのランナーに残したまま同じワークフロー内で併用できるため、パイプラインの他の部分の導入は妨げられません。

References