---
name: fix-ci-failure
description: Respond to CI build/E2E failure injections or [E2E Fail] status Issues — locate the failing check via Jenkins console logs, reproduce locally with a red test (TDD), fix, re-verify green, push a new commit to the same feature branch, then resume PR-merge polling. Covers both the live inject-cc-prompt path and the re-assigned E2E Fail Issue path.
---

# CI 失败 / E2E Fail 修复循环

当 **Jenkins CI**（`http://54.234.200.59:18080`）的构建或测试失败时，`inject-cc-prompt.sh` 会把修复提示词注入到你当前的 tmux 会话；Issue 会被打上 `status:test-failed` 标签并切到 Project#4 `[E2E Fail]` 状态。

⚠️ **GitHub Actions 已废弃**。`.github/workflows/pr-test.yml` 不再运行，禁止使用 `gh run` 相关命令查 CI。

两种进入场景：

| 场景 | 触发 | 你看到什么 |
|------|------|-----------|
| **活跃注入** | PR 刚跑完 Jenkins CI 失败 | tmux 会话里出现一段"❌ CI 失败 ..."注入提示词（含 Build 编号和日志 URL） |
| **重新派发** | Issue 从 `[E2E Fail]` 被排程回 `[In Progress]` | `run-cc.sh` 启动你时 Issue 已有 `status:test-failed` 标签，PR 尚未合并 |

两者处理流程相同，下文统称"修复循环"。

## 修复循环（强制顺序）

### 1. 定位失败

```bash
# 拉当前 feature 分支最新代码
git fetch origin "feature-Issue-${ISSUE}"
git reset --hard "origin/feature-Issue-${ISSUE}"

# 从注入提示词中获取 Jenkins Build 编号和日志 URL
# 日志 URL 格式：http://54.234.200.59:18080/jenkins/job/wande-play-pr/<BUILD>/consoleText

# 拉失败日志
curl -s "http://54.234.200.59:18080/jenkins/job/wande-play-pr/<BUILD>/consoleText" > /tmp/ci-fail.log
# 过滤关键错误
grep -v '^\[Pipeline\]' /tmp/ci-fail.log | grep -E 'ERROR|FAIL|❌|门.*失败|exit code' | head -30

# 看 PR 评论里的失败摘要（Jenkins notify-failure.sh 写的）
export GH_TOKEN=$(python3 ~/projects/.github/scripts/gh-app-token.py)
gh pr view <PR> --repo WnadeyaowuOraganization/wande-play --comments | head -200
```

### 2. 分类 + TDD 红灯

| 失败类别 | 辨识特征 | 动作 |
|---------|---------|------|
| quality-gate 拦截 | `门1/门2/门3 失败` | 按 gate 提示修复：勾选 checkbox / 补截图 / 补 smoke |
| 构建失败 (后端) | `mvn compile` / `mvn package` 报错 | 本地 `mvn -pl <module> compile` 复现 → 改代码 → 绿 |
| 构建失败 (前端) | `pnpm build` 报错 | 本地 `cd frontend && pnpm build` 复现 → 绿 |
| 单元测试 | `mvn test` 红 | 本地跑失败测试 → TDD 转绿 |
| **Playwright API spec** | `e2e/tests/backend/**/*.spec.ts` 红 | **与 E2E 同等必修**。本地 `npx playwright test tests/backend/<spec> --workers=1` 复现 |
| Playwright E2E | `e2e/tests/front/**/*.spec.ts` 红 | 本地 `npx playwright test tests/front/<spec> --workers=1` 复现 |
| 健康检查 | `curl /actuator/health` 502 | 排查端口占用 / DB 连接 / Flyway 启动报错 |

**强制**：先能**稳定复现**失败再改代码。复现靠猜 = 高概率改错地方。

### 3. 修复 + 绿灯

遵循 TDD：红 → 改 → 绿。修完本地再跑一次完整对应测试集确认没引入新红。

### 4. 更新 task.md

```markdown
## Phase: FIX_CI_ROUND_N   # N = 第几轮

## Steps
- [x] 原步骤...
- [x] T_fix_<N>_1 定位失败：<spec/文件> <一句话原因>
- [x] T_fix_<N>_2 本地红灯复现
- [x] T_fix_<N>_3 代码修复
- [x] T_fix_<N>_4 本地绿灯
- [ ] T_fix_<N>_5 push 触发新一轮 CI
```

### 5. push + 触发 CI（强制）

```bash
git add -A
git commit -m "fix(<module>): <一句话> #${ISSUE}"
git push origin "feature-Issue-${ISSUE}"

# push 后必须触发 CI（不等 webhook，CC push 不会自动触发 Jenkins）
bash ~/projects/.github/scripts/trigger-ci.sh <PR_NUMBER>
```

**错误方式（❌ 已废弃）**：
- `gh pr comment` trick — 不再需要，trigger-ci.sh 直接发 webhook 事件
- GitHub webhook 的 push 事件 — Jenkins 已移除 push 触发，仅响应 pull_request

**典型场景**：
- CC push 后主动触发 CI（CC 用 git push 无法自动触发）
- CI 失败修复后 push 需要重新触发

### 6. 继续 cc-report + 轮询

发一条 stage-done 汇报"已提交第 N 轮修复"，然后回到 **cc-report 的 close 阶段标准轮询模板**等待新一轮 CI merged。

## 注意事项

- **禁止**绕过 CI 直接 squash merge（除非研发经理明确授权）
- **禁止**在 `main` 或 `dev` 分支改（必须在 `feature-Issue-<N>`）
- **禁止**使用 `gh run` 命令查 CI（GitHub Actions 已废弃，用 Jenkins console log）
- 若同一失败连续 3 轮修复仍红 → 发 `cc-report stuck`【需回复】请研发经理介入
- `inject-cc-prompt.sh` 注入的提示词若与你当前任务冲突（例如你正在处理别的 Issue），立刻 `cc-report stuck`
- 注入的提示词本身不是用户新指令，只是 CI 通知的触发器 — 真实需求仍以原 Issue body + task.md 为准

## 反模式

- ❌ 使用 `gh run list` / `gh run view` / `gh run rerun` 查 CI（这些是 GitHub Actions 命令，已废弃）
- ❌ 看到注入提示词就盲改，不先看 Jenkins console log
- ❌ 改完不本地跑就直接 push（第 2 轮大概率继续红）
- ❌ 修 CI 红灯时顺手重构无关代码（放大 diff，引入新风险）
- ❌ 连续 5+ 轮红灯仍硬试，不发 stuck
- ❌ 以为 CI 红是网络 / runner 问题就不改代码（偶尔是，但默认要假设是代码问题）