ci-fix

CI の修正

CI の失敗を診断し、最小限で的を絞った差分で修正を実装します。PR を作成せず、専用ブランチに修正をプッシュします。

前提条件

作業を進める前に、GitHub CLI の認証を確認してください。

gh auth status

認証されていない場合は、まず gh auth login を実行するようユーザーに案内してください。

ワークフロー

1. 失敗した実行を特定する

失敗したワークフローの実行を特定します。PR ブランチで作業している場合：

gh pr view --json statusCheckRollup --jq '.statusCheckRollup[] | select(.conclusion == "FAILURE")'

ブランチまたは実行 ID を指定して作業している場合：

gh run list --branch <branch> --status failure --limit 5
gh run view <run-id> --verbose

2. 失敗ログを抽出する

失敗したステップのログを取得し、根本原因を特定します。

gh run view <run-id> --log-failed

さらに詳しく調べるには：

gh run view <run-id> --log --job <job-id>
gh run download <run-id> -D .artifacts/<run-id>

3. 根本原因を特定する

一般的な失敗パターンに注意してログを分析します。

• ビルド／コンパイルエラー：依存関係の不足、型エラー、構文の問題
• テストの失敗：アサーションの失敗、タイムアウト、不安定なテスト
• Lint／フォーマット：スタイル違反、未使用のインポート
• 環境の問題：シークレットの不足、権限、リソース制限

問題を解決する最小限の修正を優先してください。ワークフローの仕組みを変更するより、決定論的なコード修正が望ましいです。

4. 修正を実装する

リポジトリの既存のスタイルに合わせて、最小限かつ範囲を限定した変更を行います。

• 壊れている箇所だけを修正し、無関係なリファクタリングは避けます
• 可能な限り、変更を失敗したジョブ／ステップに限定します
• ワークフローファイルを変更する場合は、既存の権限を維持し、トークンのアクセス範囲を拡大しないでください

5. 修正ブランチにプッシュする

専用の修正ブランチを作成または更新します。

git checkout -b ci-fix/<original-branch>
git add -A
git commit -m "fix: resolve CI failure in <job-name>

Co-Authored-By: Warp <[email protected]>"
git push -u origin ci-fix/<original-branch>

修正ブランチがすでに存在する場合は、更新します。

git checkout ci-fix/<original-branch>
git pull origin <original-branch>
# make fixes
git commit -m "fix: <description>

Co-Authored-By: Warp <[email protected]>"
git push

6. 修正を検証する

修正ブランチで CI を実行し、進捗を確認します。

gh run list --branch ci-fix/<original-branch> --limit 1
gh run watch <new-run-id> --exit-status

失敗したジョブのみを再実行するには：

gh run rerun <run-id> --failed

安全に関する注意事項

• 明示的に依頼された場合を除き、pull_request_target は避けてください。信頼されていないコードにシークレットが公開されるおそれがあります
• ワークフローの permissions: は最小限に保ち、テストを通すためにアクセス権を拡大しないでください
• 不安定なテストには、むやみに再実行するのではなく、決定論的な修正を優先してください

成果物

修正後、次の内容を簡潔にまとめてください。

• 失敗した実行：リンクまたは ID
• 根本原因：何が、なぜ壊れていたか
• 修正：変更内容
• 検証：ステータスが成功になった新しい実行のリンク