iterate-pr

迭代处理 PR，直到 CI 通过

持续迭代当前分支，直到所有 CI 检查通过且审查反馈得到处理。

要求：已完成身份验证且可用的 GitHub CLI（gh）。

流程

步骤 1：查找 PR

gh pr view --json number,url,headRefName,baseRefName

如果当前分支没有 PR，请停止并告知用户。

步骤 2：先检查 CI 状态

在查看审查反馈前，务必先检查 CI/GitHub Actions 状态：

gh pr checks --json name,state,bucket,link,workflow

bucket 字段将状态分为：pass、fail、pending、skipping 或 cancel。

**重要：**如果以下任何检查仍处于 pending 状态，请先等待：

• sentry / sentry-io
• codecov
• cursor / bugbot / seer
• 任何代码检查或代码分析检查

这些机器人可能会在检查完成后发布更多反馈评论。等待可以避免重复工作。

步骤 3：收集审查反馈

CI 检查（或至少与机器人相关的检查）完成后，收集人工和机器人的反馈：

审查评论和状态：

gh pr view --json reviews,comments,reviewDecision

代码行内审查评论：

gh api repos/{owner}/{repo}/pulls/{pr_number}/comments

PR 对话评论（包括机器人评论）：

gh api repos/{owner}/{repo}/issues/{pr_number}/comments

留意来自 Sentry、Codecov、Cursor、Bugbot、Seer 及其他自动化工具的机器人评论。

步骤 4：调查失败原因

对于每项 CI 失败，获取实际日志：

# List recent runs for this branch
gh run list --branch $(git branch --show-current) --limit 5 --json databaseId,name,status,conclusion

# View failed logs for a specific run
gh run view <run-id> --log-failed

不要仅凭检查名称推测失败原因。务必查看实际日志。

步骤 5：验证反馈

对于每条反馈（CI 失败或审查评论）：

1. 阅读相关代码——修改前先了解上下文
2. 确认问题确实存在——并非所有反馈都正确；审查者和机器人也可能出错
3. 检查问题是否已处理——后续提交可能已经修复了问题
4. 跳过无效反馈——如果问题不成立，请继续处理下一项

步骤 6：处理有效问题

进行最小化、针对性的代码修改。只修复实际存在的问题。

步骤 7：提交并推送

git add -A
git commit -m "fix: <descriptive message of what was fixed>"
git push

步骤 8：等待 CI

使用内置的监视功能：

gh pr checks --watch --interval 30

此功能会等待所有检查完成。退出代码为 0 表示全部通过，退出代码为 1 表示存在失败。

或者，如果需要更多控制，可以手动轮询：

gh pr checks --json name,state,bucket | jq '.[] | select(.bucket != "pass")'

步骤 9：重复

如果出现以下情况，请返回步骤 2：

• 任意 CI 检查失败
• 出现新的审查反馈

持续执行，直到所有检查通过且没有未处理的反馈。

退出条件

成功：

• 所有 CI 检查均为绿色（bucket: pass）
• 没有尚未处理的人工审查反馈

寻求帮助：

• 同一失败尝试 3 次后仍然存在（可能是易失败测试或更深层的问题）
• 审查反馈需要用户澄清或作出决定
• CI 失败与分支更改无关（基础设施问题）

立即停止：

• 当前分支没有 PR
• 分支不同步，需要变基（告知用户）

提示

• 使用 gh pr checks --required，只关注必需检查
• 使用 gh run view <run-id> --verbose 查看所有作业步骤，而不只是失败步骤
• 如果检查来自外部服务，检查 JSON 中的 link 字段会提供调查所需的 URL