fix-github-actions-ci

# 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'`
- 調査完了後は、そのまま修正作業まで続けて、完了条件を満たしたら 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 をメモする:

```bash
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 を取得する:

```bash
gh run list --branch <branch> --workflow "<workflow-name>"
```

取得した run ID でログを確認する:

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

ログからファイル名・行番号・エラーメッセージを特定する。

### Step 4: workflow からローカル確認コマンドを特定する

Step 2 で取得した workflow name から workflow の YAML ファイルを取得する。
なお、workflow name は space を含む可能性があるので quote すること。

```bash
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: 修正方針をまとめる

次の形式で簡潔に整理して返す。
修正方針は「どのようなエラーが出ており、どのコードや設定を修正すべきか」を明記すること。

```markdown
## 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 する。