fix-github-actions-ci
Tips
gh pr checks --watchやgh run watch <run-id>を使うと、CI の再実行後の状況をリアルタイムで確認できますが、 結構時間がかかるので background に移譲して非同期実行してください。- すべての gh コマンドについて、
--repoでリポジトリを明確にすることをおすすめします- 現在いるリポジトリの owner/repo 形式: !
gh repo view --json owner,name --jq '.owner.login+"/"+.name'
- 現在いるリポジトリの owner/repo 形式: !
- 調査完了後は、そのまま修正作業まで続けて、完了条件を満たしたら push して PR に反映させるところまで行うことを目指してください。
Steps
Step 1: PR コンテキストの確認
現在のブランチに関連する PR を確認する:
!gh pr view --json url,number 2>/dev/null || echo "No PR found for current branch"
PR が見つからない場合はユーザーにどの PR を修正するか確認し、以降の操作でその PR を指定する。 PR コンテキストとして受け付けられる形式: PR 番号、URL、ブランチ名
Step 2: Check ステータスの確認
失敗している check と workflow name を特定し、失敗した run の ID をメモする:
gh pr checks <PR> --json name,state,bucket,workflow --jq '[.[] | select(.bucket == "fail")]'
複数の workflow が失敗している場合は、静的解析系(lint, type-check など)の workflow を優先して調査する。静的解析系 workflow の Step 3〜5 を完了後、その他の failing workflow(E2E など)についても同様に Step 3〜5 を実施する。
Step 3: 失敗ログの取得
gh pr checks の出力には run ID が含まれないため、まず run ID を取得する:
gh run list --branch <branch> --workflow "<workflow-name>"
取得した run ID でログを確認する:
gh run view <run-id> --log-failed
ログからファイル名・行番号・エラーメッセージを特定する。
Step 4: workflow からローカル確認コマンドを特定する
Step 2 で取得した workflow name から workflow の YAML ファイルを取得する。 なお、workflow name は space を含む可能性があるので quote すること。
gh workflow view "<workflow-name>" --yaml
ログと照合しながら、needs: による job 間依存により実行されなかった可能性のある job を特定する。
自動テスト系の時間がかかるチェック以外の静的解析 step をすべてリストアップし、そのコマンドを Step 5 の "How to verify locally" に記載する。
テストと判断する基準: step 名やコマンドに test, spec, e2e, coverage, vrt などのキーワードが含まれるもの。
テスト系はローカル確認コマンドとして列挙しないが、Step 3 のログで確認したテスト系のエラーは Step 5 の Error location に記録する。
Step 5: 修正方針をまとめる
次の形式で簡潔に整理して返す。 修正方針は「どのようなエラーが出ており、どのコードや設定を修正すべきか」を明記すること。
## CI failure summary
- PR context: <PR number/url/branch>
- Failed check: <check name>
- Workflow: <workflow name>
- Run ID: <run id>
## Error location
<!-- 複数ある場合はこのブロックを繰り返す -->
- File: <path or unknown>
- Line: <line or unknown>
- Message: <error message>
- Why it is failing: <root cause hypothesis based on log>
## How to verify locally
- <command 1>
- <command 2>
## Suggested fix location
- <file or component to modify based on error location and workflow steps>
- <additional risk or fail-fast note if relevant>
## Done condition
- <what output or command result should indicate the error is resolved>
Step 6: 修正を実施する
Step 5 のサマリをもとに、実際にコードを修正する。修正後は Done condition に記載したコマンドでローカル確認を行い、エラーが解消されたことを確認し、修正内容を commit して PR に push する。