circleci-builds

CircleCI ビルド

概要

このスキルを使用して、失敗した CircleCI パイプラインを、明確な根拠に基づく実行可能な修正につなげます。迅速な根本原因の特定、安全性を保った最小限のパッチ、明示的な検証基準を優先してください。

失敗をコード／設定で修正すべきか、再試行すべきか、再実行の動作で緩和すべきか、または外部要因／一時的な障害として報告すべきかを判断するときは、references/transient-vs-deterministic.md を読んでください。 失敗がテストメタデータの欠落、不安定なテストの再実行、テストの分割、または JUnit XML の設定に関係する場合は、../config/references/test-results.md を読んでください。

収集する入力情報

• 失敗したパイプライン／ワークフロー／ジョブの識別子
• ブランチとコミット SHA
• 最初に失敗したステップと主なログ行
• 同じコミットでの再実行でも失敗が再現するかどうか

ワークフロー

1. 主な失敗シグナルを特定します。
   • 後続の失敗をすべて記録するのではなく、最初に失敗したジョブとステップを記録します。
2. 問題の種類を分類します。
   • 設定の構文／参照の問題
   • 環境／ツールチェーンの不一致
   • 依存関係／キャッシュの問題
   • テストまたはビルドのリグレッション
   • 外部要因／一時的な障害
3. 実行可能な最小限の修正を適用します。
   • 確認済みの根本原因に関係するファイルだけを修正します。
   • 回避策の適用範囲を狭く保ちます。
4. 検証します。
   • 可能であれば、シグナルの強いローカルチェックを実行します。
   • 再実行時に CircleCI で期待する成功シグナルを定義します。
5. 残存リスクを報告します。
   • 未検証の前提と、追加で確認すべき可能性が高い項目を明記します。

ガードレール

• 一律の再試行で、決定的な失敗を隠さないでください。
• インシデント修正に無関係なリファクタリングを混在させないでください。
• 外部サービスの停止は、ユーザーがより踏み込んだ再設計を求めない限り、報告して緩和する問題として扱ってください。
• ログが不完全な場合は、確信度を明示してください。
• 失敗が一時的なものである可能性が妥当と分類されるまでは、自動再実行や不安定なテストのワークフローを推奨しないでください。

出力要件

以下を提示します。

1. 失敗の概要（パイプライン／ワークフロー／ジョブ／ステップ）。
2. 根本原因の仮説と確信度。
3. 適用した変更とファイル一覧。
4. 検証計画と期待する合格シグナル。
5. 残存リスク。