コンテンツへスキップ
Latchkey
ドキュメントメニュー

Runners ページ: フリート管理

ダッシュボードからランナーフリートを管理します: 構成、ランナーごとの自己修復トグル、使用量と節約、Recent Heals フィード、一括移行ツール。

Latchkey の Runners ページ
Runners ページ: フリートのメトリクスとあなたのランナー構成。

マネージドランナーフリートに関するすべては、ダッシュボードのサイドバーにある Latchkey Runners ページにあります。このセクションの残りで説明する機能の運用上の拠点です。

ページに何があるか#

フリートメトリクスこの課金期間のランナーコスト、GitHub ホステッド比の推定節約額、そして月間の割り当てに対して使用した無料ティアの分数。
Runner Typesスペックと 1 分あたりの価格を備えたプリセットサイズで、ラベルを選ぶ際に常に手元にあります。
Your runnersワークスペース内のすべての構成: サイズ、イメージビルド状況、最大同時実行数、オン/オフの状態、そして行ごとの Copy CI snippet アクション。
自己修復アクティビティ修復の KPI、傾向、カテゴリ別の内訳、そして Recent Heals フィード。

5 分間の週次レビュー#

このページは短い週次の習慣に報います。おすすめのパス:

週次フリートレビュー

Your runners テーブル#

Your runners テーブルは、ワークスペース内のすべての構成を一覧します: 4 つのプリセットに加えて、あらゆるカスタムランナー。各行はサイズ、イメージビルド状況、最大同時実行数、オン/オフの状態を示し、さらに誰もラベルを記憶から入力しなくて済むよう行ごとの Copy CI snippet アクションを備えています。各行では次のことができます:

  • 有効化/無効化。 無効化した構成は新しいジョブの受け入れを停止します (そのラベルを狙ったジョブはキューに入ります)。
  • 構成ごとの自己修復トグル。設定にあるワークスペースレベルのモードに加えて、特定のランナータイプを修復から除外できます。
  • カスタムランナーイメージビルド状況: カスタムイメージがまだビルド中か、準備完了かを確認できます。
  • 不要になったカスタム構成の 削除

無効化と削除は別の仕事をします。無効化は一時停止ボタンです: ラベルは存在し続け、それを狙ったジョブは再度有効化するまでキューに入ります。構成を調査している間の正しい手段です。削除は、永久に用済みになったカスタム構成のためのものです。構成ごとの修復トグルは精密なツールです: 設定にあるワークスペース全体のモードに触れることなく、1 つのランナータイプを除いてどこでも自己修復をオンに保てます。

詳細ドロワー#

行をクリックすると、完全な構成を含む詳細ドロワーが開きます: ラベル、OS、vCPU、RAM、ディスク、ベースイメージ、1 分あたりの価格、加えてラベルとコピー可能な GitHub Actions スニペットを備えた Use in CI カード。管理者はランナー名、カスタムラベル、Max Concurrent (0 = 無制限) を編集できます。管理者以外は同じ詳細を読み取り専用で見るため、チーム全員が各ランナーの提供内容を確認できます。

Recent Heals#

自己修復セクションは、各修復をその判定とカテゴリとともに一覧します。行を開くと完全なレポートが表示されます: 何が失敗したか、診断、取られた正確なアクション (平易な言葉で)、そして AI が診断した障害についてはエージェントのイテレーション。パイプラインパフォーマンス で修復された実行は、同じレポートへのディープリンクになっています。自己修復がオフの場合、このセクションは設定のトグルへリンクします。

このフィードは単なる救済ログではなく、シグナルとして読んでください。多くのワークフローに散らばった単発のネットワーク修復は、レジストリや外部サービスが調子を崩す通常のバックグラウンドノイズです。パターンのほうが興味深いです: 同じワークフローが同じカテゴリで繰り返し修復されるのは、根深い何かを指しています。メモリ修復の繰り返しは より大きなランナーサイズ を求めるジョブを示唆し、ディスク修復の繰り返しは毎回ディスクを満杯にするジョブを、ツール修復の繰り返しはワークフローが決してインストールしないツールを前提とするステップを示唆します。これらこそ、毎晩救済されるより恒久的な修正が勝るケースです。自己修復がそうした修正をどのように自ら提案するかは 修復プルリクエスト を参照してください。

Migrate Runners#

01ツールを開くRunner Types カードから (オーナーと管理者)
02リポジトリを選ぶ検索可能なリストから最大 20 の監視対象リポジトリ
03移行 PR を開くLatchkey がリポジトリごとに 1 つのプルリクエストを開きます
04レビューしてマージチームが各 PR をマージするまで何も変わりません

各プルリクエストは、サポートされるすべての runs-on ラベルを Latchkey ランナーに書き換えます: 標準の Ubuntu ラベルは最低コストのサイズである latchkey-small に切り替わり、その他のサポート対象ラベルは、その CPU とメモリを満たす最小の Latchkey サイズに切り替わります。変更されるのは runs-on の行だけです。各 PR 本文が述べるとおり、"Only runs-on: lines were touched. Every other line in each file is byte-identical." 各ファイルの変更前後のマッピングテーブルが、何が変わったかを正確に示すため、レビューには数日ではなく数分しかかかりません。

  • PR が開かれると、モーダルはそれぞれを PR 番号と View PR リンクとともに一覧します: "Opened N pull requests. Merge each on your schedule."
  • リポジトリに既に開いている移行プルリクエストがある場合、Latchkey は重複を開く代わりにそれへリンクします。
  • 切り替えるものが何も残っていない場合、モーダルは Nothing to migrate の状態を表示します。
  • 移行 PR を開くには管理者またはオーナーのロールが必要です。チームがマージするまで、あなたのリポジトリでは何も変わりません。

このツールは意図的にいくつかのものをそのままにします: Windows と macOS のジョブ、認識しない self-hosted ラベル、そして ${{ matrix.os }} のような matrix 式 (matrix の軸定義を含む)。これらのジョブは今日と全く同じ場所で実行され続けるため、Linux ジョブを今すぐ移行しつつ、OS 混在のワークフローは安全に手を付けずに残せます。

このツールのおすすめのリズム: 一度にすべてではなく、波状に移行します。最初のワークフローを手動で移動し (1 行の YAML)、1 週間実行させ、ここで見る数字を信頼できるようになったらフリートの大部分を移行します。