ci-triage

CI トリアージ

対象範囲

このスキルは、証拠に基づく分類を担当します。リポジトリの契約／オーバーレイは、 再現コマンド、想定される失敗、イシューの規約、警告の重大度を担当します。 トリアージによって、コードの公開、リバート、イシューやコメントの作成、メンションが 許可されることはありません。修正によって許可済みの PR が変更される場合は、 pr-lifecycle を読み込んでください。

前提条件

実行、ワークフロー、テスト対象の正確な SHA、イベントを特定します。PR の場合は、 ヘッドとテスト対象のマージプレビューを区別してください。チェックやログの取得に 機能マッピングが必要な場合は、 harness-operations を使用してください。 認証とログの利用可否は実際に確認してください。すべてのコネクターが同じフィールドや 制限を公開していると想定してはいけません。

手順

1. 利用可能な GitHub ツールを使って、実行／ジョブのステータス、最初に失敗したステップ、 範囲を限定したログを読み取ります。認証情報と個人データは伏せてください。ログを 利用できない場合は、ステータス／設定の証拠を保持し、アクセス上の制限を報告します。
2. ワークフロー、入力、依存関係、環境を含め、テスト対象の差分を直前の比較可能な実行と 比較します。以前のコミットが成功していたことだけでは、フレークであることの証明にも、 原因の証明にもなりません。証拠をもとに疑わしい変更を特定します。マージメッセージの 形式だけから作成者を責めてはいけません。
3. 許可された隔離済みチェックアウトで、テスト対象の正確なリファレンスまたはマージ結果を 使い、そのリポジトリ固有のゲートコマンドとフィクスチャで再現します。保留中の プライマリチェックアウトを疑わしいブランチに切り替えてはいけません。ブラウザーの 失敗には、リポジトリのブラウザーワークフローを使用してください。他製品のルートや フィクスチャで代用することはできません。
4. 次の分類体系で分類します。ログ、認証情報、ツール、再現可能な環境が不足している場合は 確信度に影響します。推測せず、その不足を報告してください。
5. 許可されている場合に限り、リポジトリのイシュー規約に従います。継続的な main-red イシューを使用する場合は、新規作成の前に既存のオープントラッカーを検索してください。 重複を作成する代わりに、簡潔な証拠を追記します。テンプレートにメンションが含まれて いるだけで人に通知してはいけません。トラッカーをクローズするのは、権限があり、 対象ワークフローの成功した実行を引用できる場合に限ります。
6. 修正する場合は、リポジトリのワークフローと、プッシュ前／PR のライフサイクルに 引き継ぎます。再試行する場合は、失敗した実行を保持し、同じテスト対象の入力を比較します。 再試行が成功しただけでは、必須アサーションを弱める根拠になりません。

分類

分類	証拠	次のアクション
回帰	テスト対象の変更、またはそのマージ後の相互作用に結び付く決定的な失敗	実証された不具合を再現して修正する
フレーク	同等の入力で結果が異なり、非決定的な原因を示す証拠がある	記録／再試行し、原因に対処する
インフラ	製品アサーションとは独立して、ランナー、サービス、ネットワーク、依存関係のプロビジョニングに失敗した	環境を修復／再試行する
人による確認が必要	信頼できる診断には証拠または権限が不十分	利用可能な証拠を集める。保留中の人による判断が必要な場合は、harness-operations の構造化質問機能を使って依頼する

人が次のアクションを選択する必要がある場合や、不足しているコンテキストを提供する必要がある場合は、 harness-operations の構造化質問機能を使い、その後、 依存する作業に着手する前に返答を待ちます。ツールが利用可能な場合、テキストだけで 「人による確認が必要」と報告しても、その判断を依頼したことにはなりません。利用できない 場合は、その制限を明記し、確立された引き継ぎチャネルを使用してください。インフラの不足 だけで人による選択が必要になるわけではありません。

完了

ワークフロー／実行 URL、テスト対象の SHA、最初に失敗したステップ、分類、確信度、 再現結果、範囲を限定した証拠、次のアクションを報告します。再現が阻止された場合は、 ローカルチェックに成功したことにはなりません。チェックのステータスは、正確な SHA に 紐付けてください。