リポジトリの管理

リポジトリごとに監視を有効/無効にし、プラン上限を理解し、AI が分析するブランチを選び、履歴のバックフィルがカバーする範囲を把握します。

Latchkey は、明示的に有効にしたリポジトリのデータのみを取り込みます。オンボーディング中にそれらを選択し、ダッシュボードからいつでも変更できます。有効化はリポジトリをマネージドランナーの対象にするものでもあります。マネージドランナーは監視対象のリポジトリのみを扱います。

監視モーダル#

ダッシュボードのサイドバーで Monitoring (ワークスペースの owner と admin に表示) をクリックすると、リポジトリ監視の管理 が開きます。ヘッダーには、プラン上限に対して使用しているリポジトリ数が表示されます。各リポジトリにはトグルがあり、変更は「保留中の変更」としてキューに入り、変更を保存 をクリックすると一緒に適用されます。

• 検索とスクロール: リストは組織をリアルタイムで検索し、スクロールに応じてさらに読み込みます。
• ブランチセレクター: 監視対象の各リポジトリには、Latchkey の AI がワークフロー最適化のために分析するブランチを設定するブランチピッカーが表示されます (デフォルトはリポジトリのデフォルトブランチ)。他のブランチにのみ存在するワークフローは分析されません。
• 権限: 監視の有効化と無効化には owner または admin ロールが必要です。

プラン上限#

上限に達すると、追加のトグルはブロックされ、モーダルがアップグレードを案内します。Developer では、唯一の監視対象リポジトリをモーダルから入れ替えることはできません。Launch または Scale へのアップグレードでこれが解除されます。

上限内でリポジトリを選ぶ#

スロットよりリポジトリが多い場合は、上限を優先順位付けの問題として扱ってください。

• マネージドランナーで動かしたいものはすべて監視する必要があります。 監視対象外のリポジトリから latchkey-* ラベルを狙うジョブはピックアップされず、GitHub 上でキュー待機のままになります。ランナーの導入が目的なら、それらのリポジトリを優先します。
• アクティビティの多いリポジトリは、分析に最も多くの材料を与えます。 ダッシュボードと AI の推奨事項はワークフローの実行から構築されるため、1 日に何度も CI を実行するリポジトリは、週に 1 回ビルドするものよりはるかに多くのシグナルを生み出します。
• 慢性的に失敗するパイプラインは有力な候補です。 連続した失敗の繰り返しは診断分析をトリガーするため、不安定なリポジトリは AI が最初に真価を発揮する場所であることが多いです。最適化インサイト をご覧ください。
• Developer では慎重に選んでください。 唯一の監視対象リポジトリはモーダルから入れ替えられないため、CI を最も理解したいリポジトリを選んでください。Launch または Scale へのアップグレードで入れ替えが解除されます。

リポジトリを有効にすると何が起こるか#

バックフィルと最初の AI 分析の実行中はダッシュボードに進捗バナーが表示されるため、何がまだウォームアップ中かが常にわかります。

バックフィルがカバーするものとしないもの#

バックフィルは、1 週間データを集めた後ではなく初日からダッシュボードを役立てるために存在します。直近 30 日間の 完了済み 実行をインポートし、これはコスト、パフォーマンス、インサイトのページを実際の数字で埋めるのに十分です。ほとんどのチームは数分でデータを確認できます。設定しておくべき期待が 2 つあります。これはサンプルであって完全な履歴のインポートではないこと、そして存在するものしかインポートできないことです。直近 30 日間にワークフローの実行がないリポジトリは何もバックフィルせず、新しい実行が起きるまでそのページは空のままです。ダッシュボードの日付範囲フィルターもアクティビティと重なる必要があるため、バックフィル直後にページが空に見える場合は、何か問題があると決めつける前に範囲を広げてください。

リポジトリを無効にすると何が起こるか#

無効化すると、そのリポジトリの取り込みが直ちに停止し、プラン上限に対するスロットが解放されます。その履歴データはダッシュボードに表示される代わりにアーカイブされます。マネージドランナーは監視対象のリポジトリのみを扱うため、そのリポジトリで latchkey-* ラベルを狙うジョブは、再度有効にするまで実行されずにキュー待機になります。後で再度有効にすると、新しいバックフィルが始まります。

よくある質問#