loop-on-ci

用途

Loop on CI 用于在开发过程中持续监控某个分支或 Pull Request 的 CI 检查，并针对失败项进行迭代修复，直到所有必需检查变为绿色。它适合需要反复推送代码、等待 CI 结果并处理失败反馈的场景。

主要能力

• 解析当前分支对应的 PR，获取 PR 编号、URL 和分支名。
• 在等待之前先检查当前 PR 的检查状态，避免盲目等待。
• 对已经失败的检查优先进行诊断，而不是直接进入等待。
• 对处于 pending 状态的检查使用监视模式，并在出现失败时快速退出。
• 每次推送后重新检查完整的 PR 检查集合，因为检查集合可能发生变化。
• 当失败的检查链接到 GitHub Actions 运行时，可查看失败日志。

使用方式

技能以 gh pr checks 作为 PR 检查状态的唯一依据，理由是它包含所有附加到 PR 的检查，而 gh run list 只覆盖 GitHub Actions。

工作流步骤：

1. 解析当前分支对应的 PR。
2. 在等待前检查当前 PR 检查状态。
3. 如果检查已经失败，先诊断这些失败。
4. 如果检查仍在进行中，使用监视命令等待。
5. 每次推送后重新检查完整的 PR 检查集合，重复直到全部通过。

相关命令：

# Resolve the active PR
gh pr view --json number,url,headRefName

# Inspect all attached checks
gh pr checks --json name,bucket,state,workflow,link

# Watch pending checks and fail fast
gh pr checks --watch --fail-fast

# GitHub Actions logs, when the failing check links to a GHA run
gh run view <run-id> --log-failed

适用场景

• 需要持续观察某个分支或 PR 的 CI 状态。
• 需要针对 CI 失败进行迭代修复，直到所有必需检查通过。
• 失败检查链接到 GitHub Actions 运行，需要查看失败日志定位问题。

限制与约束

• 尽可能让每次修复只针对一个失败原因。
• 不要使用 --no-verify 绕过钩子来强行推进。
• 如果失败明显与 PR 无关且看起来已在 main 上修复，应合并最新 main，而不是把无关修复塞进 PR。
• 如果失败是不稳定的（flaky），重试一次并报告不稳定的证据。
• 每次推送后都要重新运行检查命令，因为检查集合可能变化。

输出

• 当前 CI 状态。
• 失败摘要与已应用的修复。
• 检查通过后的 PR URL。