コンテンツへスキップ
Latchkey
EnglishPortuguês日本語
無料で始める
ドキュメントメニュー

はじめに

ダッシュボードと分析

マネージドランナー

キャッシュ

チームと通知

請求とプラン

ヘルプ

Runners ページ: フリート管理

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

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

マネージドランナーフリートに関するすべては、ダッシュボードのサイドバーにある Runners ページ ("Manage your runners and review jobs they've run") にあります。このセクションの残りで説明する機能の運用上の拠点です。

ページに何があるか#

フリートメトリクスこの課金期間のランナーコスト、GitHub ホステッド比の推定節約額、そして月間の割り当てに対して使用した無料ティアの分数。
Runner TypesPreset Runners (スペックと 1 分あたりの価格を備えた 4 つのサイズ) と AI Scan Runners をカバーする折りたたみ可能なカードで、フッターには Migrate Runners のショートカットがあります。
Your runnersワークスペース内のすべての構成: 名前、ステータス、サイズ、最大同時実行数、自己修復の状態、オン/オフ、そして行ごとの Copy CI snippet アクション。
自己修復アクティビティ修復の KPI (Total Attempts、Heals、Success Rate)、アクティビティとカテゴリのチャート、そして Recent Heals フィード。

5 分間の週次レビュー#

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

週次フリートレビュー

Your runners テーブル#

Your runners テーブル ("Set up runners for your repos. Adjust size, concurrency, and on/off state.") は、ワークスペース内のすべての構成を一覧します: 4 つのプリセットに加えて、あらゆるカスタムランナー。列は名前、ステータス、サイズ、最大同時実行数、自己修復の状態、アクティブ状態をカバーし、テーブルヘッダーには AI Scan Runners アクションがあります。最初のランナーを作る前は Set up your first runner の空の状態が表示され、保留中のスキャンバナー ("Ready for review") がその上に現れます。各行では次のことができます:

  • 有効化/無効化。 無効化した構成は新しいジョブの受け入れを停止します (そのラベルを狙ったジョブはキューに入ります)。
  • Copy CI snippet: 誰もラベルを記憶から入力しなくて済むようにします。
  • 修復がそのランナーをカバーしているかを示す Self Healing 列。コントロール自体は Settings、Self-Healing にあるワークスペース全体のスイッチです。
  • カスタムランナー の イメージビルド状況: カスタムイメージがまだビルド中か、準備完了かを確認できます。
  • 不要になったカスタム構成の 削除。

無効化と削除は別の仕事をします。無効化は一時停止ボタンです: ラベルは存在し続け、それを狙ったジョブは再度有効化するまでキューに入ります。構成を調査している間の正しい手段です。削除は、永久に用済みになったカスタム構成のためのものです。

詳細ドロワー#

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

Recent Heals#

自己修復セクション ("Recent heal attempts, agent reports, and PR proposals across your org.") は、修復の KPI と Heal Activity Over Time および Heal Rate by Category チャートの下に、各修復をその結果バッジ (Healed、No Action、Failed、または Pending) とカテゴリとともに一覧します。行をクリックすると、完全なレポートを含む Heal Details ドロワーが開きます: 何が失敗したか、診断、取られた正確なアクション (平易な言葉で)、そして AI が診断した障害についてはエージェントのイテレーション。パイプラインパフォーマンス で修復された実行は、同じレポートへのディープリンクになっています。自己修復がオフの場合、このセクションは "Self-Healing is disabled." と表示し、Settings で有効化するためのリンクを示します。

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

Migrate Runners#

Migrate runners モーダル
Migrate runners モーダル: 最大 20 の監視対象リポジトリを選び、リポジトリごとに 1 つの移行 PR を開きます。

このツールには 2 つの入口があり、どちらも同じ Migrate runners モーダルを開きます: ダッシュボードのサイドバーにある Migrate Runners 項目と、Runner Types カードのフッターにある CTA ("Already have workflows on GitHub-hosted runners? Migrate them to Latchkey runners in a few clicks.") です。このセクションはモーダルそのものを扱います。正確なラベルマッピング、PR の内容、検証、ロールバックを含む完全なガイドは GitHub ホステッドランナーからの移行 です。

01ツールを開くサイドバー項目または Runner Types カードのフッターから (オーナーと管理者)
02リポジトリを選ぶ最大 20 の監視対象リポジトリ。選択数を示す N/20 のカウンター付き
03移行 PR を開くLatchkey がリポジトリごとに 1 つのプルリクエストを開きます
04レビューしてマージチームが各 PR をマージするまで何も変わりません

各プルリクエストは、サポートされるすべての runs-on ラベルを適切な Latchkey サイズに書き換え (標準の Ubuntu ラベルは latchkey-small になります)、それ以外には一切触れません。Windows と macOS のジョブ、認識されないラベル、${{ }} 式を含む行はそのまま残されます。各ファイルの変更前後のマッピングテーブルが、何が変わったかを正確に示すため、レビューには数日ではなく数分しかかかりません。

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

References