トラブルシューティング

以下の各セクションは1つの症状を扱い、確認する価値が高い順に原因を並べています。ほとんどの問題はどこかで自らを知らせます: ダッシュボードのバナー、ベルの通知、またはモーダルのステータスです。この表は、まずどこを見ればよいかを示します。

Latchkeyランナーを対象とするジョブがキューのままになる#

これは、ランナーのプロビジョニングを妨げるあらゆる事象に共通する症状です。GitHubは、一致するラベルを持つランナーがジョブを取得するまでジョブを「キュー」に保ちます。そしてLatchkeyが起動をブロックまたはルーティングできない場合、GitHub側にエラーは表示されず、ジョブは単に待機します。つまり診断は常にLatchkey側で行われます。何も問題がないときにプロビジョニングがウォームピックアップとコールドスタートのどちらを選ぶかについては、プロビジョニングの仕組みを参照してください。次の順序でトリアージしてください:

1. 01ラベルは正しい?正確なプリセットまたはカスタムラベル、タイプミスなし
2. 02リポジトリは監視中?モニタリングモーダルを確認
3. 03設定は有効?無効な設定はジョブの受け付けを停止します
4. 04請求は問題なし?トライアル、サブスクリプション、無料枠の状態
5. 05イメージは準備完了?カスタムランナーのビルドには時間がかかります
6. 06上限に達している?すべてのワークスペースは40件の同時ジョブから始まります(Launchプランの数値)

ダッシュボードにデータが表示されない#

空のダッシュボードは、ほぼ常にフィルターやタイミングを意味し、データの消失ではありません。次の順序で確認してください:

1. リポジトリが選択されていない。 Command & Control は Filters で選択されたリポジトリを表示します。確認方法: リポジトリが選択されていない場合、ワークフローのセレクターは無効になり、"Select a repository first" と表示されます。Reset filters (Easy では Reset) はすべてのリポジトリとワークフローを再び選択し、Date range のウィンドウを直近30日に戻します。
2. バックフィルがまだ実行中。 新しく有効化されたリポジトリは、まず最近の履歴をインポートし、ほとんどのチームは数分以内にデータを目にします。確認方法: インポートが完了するまでバックフィルの進捗バナーがダッシュボードに表示されます。バナーが消えるのを待ってからページを判断してください。
3. 期間内に実行がない。 バックフィルは過去30日間の完了した実行を対象とし、Date range のウィンドウは実際のアクティビティと重なる必要があります。確認方法: GitHubでのリポジトリの最近のワークフロー実行から、直近の実行がバックフィル期間より前かどうかがわかり、前であれば、新しい実行が発生するまでページは空のままです。既定のウィンドウである直近30日間は、バックフィル期間と一致します。
4. アプリが誤った組織にインストールされている。 GitHub Appがリポジトリを所有する組織にインストールされていない場合、イベントはまったく届きません。確認方法: GitHubで組織のSettings、次にGitHub Appsを開き、Latchkeyがそこに表示されていることを確認します。正しい組織にインストールして修正してください。GitHub Appのインストールを参照してください。

AIインサイトが表示されない#

インサイトの生成は自動かつイベント駆動であり、押すボタンはありません。エージェントは、新しく監視されたリポジトリの初回バックフィル後、分析ブランチでワークフローファイルが変更されたとき、連続した繰り返し失敗のとき、コストの急増のとき、そしてパフォーマンスの低下のときに実行されます。したがって「インサイトがない」は通常、トリガーがまだ発火していないか、エージェントがあなたとは異なるブランチを見ていることを意味します:

• 分析がまだ実行中、またはまだトリガーされていない。 インサイトはバックフィル完了後に自動的に生成されます。確認方法: エージェントの実行中、Insightsページに処理中バナーが表示されます。新しいリポジトリには数分の余裕を与えてください。
• 分析ブランチが誤っている。 分析は、モニタリングモーダルで選択された分析ブランチ(デフォルトではリポジトリのデフォルトブランチ)に従います。他のブランチにのみ存在するワークフローは分析されません。確認方法: モニタリングモーダルを開き、リポジトリの横にあるブランチピッカーを確認します。リポジトリの管理を参照してください。
• 本当に言うことが少ない。 小規模またはめったに実行されないワークフローは、推奨事項がほとんど生成されないことがあります。これは失敗ではなく1つの発見です。ワークフローファイルを編集すると分析が再トリガーされるため、次のワークフロー変更後に再度確認してください。

推奨事項の適用が失敗した、または変更が破棄された#

推奨事項は、分析時点で存在していたワークフローファイルに対して生成されます。それ以降にファイルが変更された場合(あなたの編集や、以前にマージされたLatchkeyのPR)、一部の推奨事項はきれいには適用できなくなります:

• Latchkeyは、まだ適合するものでPRを開き、手動での配置が必要な推奨事項を一覧表示します。PRは latchkey/insight-<detector>-<hex> ブランチ上で「Latchkey insight: <what it does>」というタイトル(例:「Latchkey insight: pin GitHub Actions to commit SHAs」)で届き、成功バナーが直接そこへのリンクを提供します。
• 選択したすべての推奨事項が破棄された場合、古いセットを再試行しないでください。ワークフローを編集すると新しい分析がトリガーされます。それが完了するのを待ち(Insightsページの処理中バナーが消えます)、新しいセットから適用してください。最適化インサイトを参照してください。

支払いが失敗し、アクセスがブロックされた#

Past Due ステータスは支払いの失敗を意味します: 支払い方法がStripeポータルで修正されるまで、ダッシュボードとAPIへのアクセスがブロックされ、ランナーの起動が停止します。Stripeポータルでは、支払い方法、請求書(PDF付き)、サブスクリプションの詳細が管理されます。代わりにサブスクリプションが Canceled の場合、アクセスはブロックされますが、再サブスクライブできるよう請求は引き続きアクセス可能です。いずれの場合もデータは保持されます。ステータスとその影響はサブスクリプションの管理に一覧されています。

スマートフォンでダッシュボードを使えない#

これは現時点では仕様です: ダッシュボードにはタブレット、ノートパソコン、またはデスクトップの画面が必要であり、幅が768 px未満の画面ではサインイン後に "A larger screen is needed" という見出しの通知が表示されます。メール、Slack、プッシュによる通知、および週次ダイジェストが、デスクを離れているときもあなたをカバーします。

個人アカウントにアプリをインストールした#

そのインストールは接続されており、そのアカウントでは、ダッシュボードから登録したリポジトリで Latchkey CI を実行できます。登録済みのリポジトリから latchkey-* ラベルを対象とする GitHub Actions のジョブは Latchkey のランナーでは実行されず、Latchkey はその理由を次のように伝えます: 「Latchkey on GH needs a GitHub organization. This personal account runs Latchkey CI: commit a workflow file under .latchkey/workflows/ and push.」ファイルについてはワークフローファイルで説明しています。個人アカウントのリポジトリでLatchkey on GH(GitHub Actionsで動くLatchkeyのマネージドランナー)を使うには、GitHub Appのインストールのとおり、リポジトリを組織に移動してください。

トライアルが終了し、すべてがブロックされた#

データは無傷です。ブロックはアクセスに対してであり、ストレージに対してではありません。ダッシュボードは「Your free trial has ended」画面に置き換えられ、APIアクセスは同じメッセージでブロックされ、マネージドランナーの起動はブロックされます(latchkey-* ラベルを対象とするジョブはエラーになるのではなくGitHubでキューのままになります)。アクティベーション画面(または到達できる場合は Billing ページ)からサブスクライブすると、ランナーの起動を含むアクセスが即座に復元されます。無料トライアルはおひとりにつき 1 回で、サブスクライブやプラン変更によって再開されることはありません。プランと無料トライアルを参照してください。

ジョブの failure_reason が意味するもの#

Latchkey CIのジョブを、あなたのコマンドが結果を決めるのではなくLatchkey自身が終了させた場合、そのジョブの failure_reason は以下のいずれかの値になります。各値はLatchkeyが記録するとおりの語なので、翻訳していません。

Latchkey自身の障害#

あなたによるキャンセル#

接続と登録#

請求と利用資格#

あなた自身の入力#

failure_reason には、取りうる値が決まっていない種類が2つあるため、表には列挙できません。1つ目は、ジョブ自身が報告した理由です。Latchkeyはそれをジョブ自身の言葉として表示し、Latchkeyチェックは赤になります。そのうちの1つである context_fetch_failed は、Latchkeyが保持していたコンテキストをジョブが取得できなかったことを意味します。Latchkeyがその障害を自らのものと確認できた場合(保持していたコンテキストが見つからない場合)、チェックはニュートラルになり、行とCLIにもその旨が表示されます。確認できない場合、チェックは赤のままで、ジョブ自身の言葉が表示されます。そのうちのもう1つである service <label> could not start は、ランナー自体が起動に失敗した場合(ホスト名の書き込み、コンテナエンジンが応答しないか起動を拒否した場合、またはエンジンクライアントを準備できなかった場合)はLatchkey側の障害で、ラベルがすでにランナー上のホスト名である場合、イメージを取得できなかった、停止した、または時間内に準備ができなかった場合はジョブ自身の失敗です。どちらであるかはジョブのログに書かれ、取得が拒否された場合はレジストリ自身のメッセージも記録されます。Latchkey側の障害の場合も、Latchkeyがその障害を自ら確認できるようになるまで、チェックは赤になります。Latchkeyはサービスを使うジョブの開始前にランナーを確認し、その確認でランナーが実行できないことが判明した場合(エンジンクライアントを準備できない、エンジンがネットワークの作成を拒否する、ホスト名を書き込む権限がない、またはジョブのためにコールドスタートしたランナーでエンジンが応答しない場合)、ジョブは代わりに別のランナーに移ります。そうして試行が尽きたジョブは、最初の表にある refused: runner_cannot_prepare_services で終了し、チェックは赤になりません。2つ目は、launch_failed: の後にエラー名が続くものです。これはLatchkeyがそのジョブのランナーを起動できなかったことを意味し、最初の表にあるものと同じくLatchkey側の障害で、再試行しても安全です。

まだ解決しませんか?#

FAQには手早い回答があります。それ以外については、サポートと Account and help メニューの Send feedback のどちらも直接チームに届きます。