ci-triage

CI トリアージ

すべての失敗を追いかける前に、信頼できる最小限のシグナルを見つけます。

プロセス

1. 失敗したチェックを記録する

失敗したコマンドまたは CI ジョブをそれぞれ、次の情報とともに列挙します。

• チェック名。
• 失敗の概要。
• 関連するログの抜粋。
• 現在のブランチ、ベースブランチ、または両方のどれで実行されたか。

スキップされたチェック、インフラストラクチャの障害、コードの障害を区別します。

2. 最も手軽なローカルシグナルを再現する

原因の候補を見分けられる、最も範囲の狭い失敗コマンドまたはプローブを再現します。フォーマット、型チェック、全テストスイートを必須の順番で実行しないでください。コンパイルやセットアップの失敗によって関連するテストを実行できない場合は、まずその失敗を解決します。独立したテストの失敗を診断するうえで関係のないリンターの失敗は、妨げる必要はありません。

失敗の依存関係や影響を受ける境界に応じて、検証範囲を広げます。

3. 必要に応じてベースと比較する

失敗が以前から存在する可能性や環境に起因する可能性がある場合は、ベースブランチまたは既知の正常なコミットに対して同じチェックを比較します。

各失敗を分類します。

• この変更によって発生 — すぐに修正します。
• 以前から存在 — 証拠を添えて報告し、依頼がない限り対象範囲を広げないでください。
• インフラストラクチャまたは環境 — 証拠を報告し、必要な再実行やアクセスを明示します。
• 不明 — 分類できるまで、またはブロッカーが明確になるまで調査を続けます。

4. 範囲を限定して修正する

修正が許可されている場合は、機械的で局所的かつ現在の変更が原因であることが明らかな、リスクの低い失敗だけを修正します。診断のみの依頼では読み取り専用にとどめ、書き込みや副作用のあるコマンドには /persistent-side-effects を適用します。対象となる修正は次のとおりです。

• フォーマッターやリンターによる自動修正。
• インポート漏れ、型専用インポート、または明らかなインポート順序の修正。
• コマンドが判明しており、実行が想定されている場合の型や生成アーティファクトの再生成。
• 意図する動作がすでに明らかな場合の、テストやフィクスチャの誤字レベルの修正。
• 検証ハーネスにのみ影響するコマンドと設定の不一致。

CI トリアージを、新しい動作の設計、テストを満たすためのプロダクトロジックの変更、広範なリファクタリング、プロダクトのバグの根本原因の推測に使わないでください。次の方法で引き継ぎます。

• 修正にコード変更の計画や機械的ではない実装が必要な場合は、/implement-plan を使用します。
• 失敗によって、原因がまだ判明していないプロダクトやランタイムの動作上のバグが明らかになった場合は、/diagnose-bug を使用します。

範囲を限定した修正を行った後は、その修正を確認できる最も狭いチェックを再実行します。

5. 状況を報告する

次の内容を報告します。

• 現在の変更が原因の失敗。
• 証拠を添えた、以前から存在する失敗または環境に起因する失敗。
• 適用した、範囲を限定した修正。
• /implement-plan または /diagnose-bug が必要な失敗。
• 再実行したコマンドとその結果。
• 残っているブロッカーと、次に必要な具体的なアーティファクト。

完了条件

各失敗したチェックが分類され、許可された安全な範囲限定の修正が適用されて再実行済み（または診断のみの作業に対して提案済み）であり、実装やバグ診断が必要な失敗が証拠とともに引き継がれ、残る失敗について、以前から存在する、環境に起因する、不安定である、またはブロックされている理由を示す証拠がそろった時点で、CI トリアージは完了です。