查看 CI 运行
监控拉取请求 CI¶
在带有已认证 gh CLI 的源码检出中，等待一个确切的拉取请求 head：
维护者使用的 GitHub 辅助工具使用调用方未修改的 PATH 上的外部 gh，因此该路由掌握凭据、过滤以及任何原生委派。“Plain” 表示规范化终端输出：辅助工具不会发现原生安装、提取默认路由令牌，也不会通过另一个二进制重试被拒绝的请求。OPENCLAW_GH_BIN 是操作者显式所有的、用于支持调用方的覆盖项；仅当它的认证和保护措施合适时才选用它。基于 PATH 的读取辅助工具（包括此监视器）会忽略该覆盖项。权威 REST 读取使用 Cache-Control: max-age=0 请求重新验证，并提供具体的仓库路径。监视器只解析一次仓库，然后在每次读取时重新验证可变的 PR 状态。写入者身份使用已认证的 REST GET /user --include；包含的响应头保留原生写入者路由，而不是接受中继的调用者档案。
在进入 PR 工作树之前，scripts/pr 会用一次请求检查该写入者。速率限制失败会在 fetch 或合并副作用之前停止操作，并且只报告来自同一响应的安全元数据：HTTP 状态、配额资源、剩余配额、限制、UTC 重置时间，以及可用的重试延迟。手动重试前请遵守 retry-after；仅当该预算耗尽时才等待主重置。对于仍有剩余配额的次级限流，未来的主重置时间并不是解除阻塞的时间。如果没有可用的重试延迟或已耗尽预算的重置时间，则至少等待 60 秒。仅凭剩余余额为零并不能将 HTTP 200 失败归因于速率限制：格式错误或缺失的身份数据以及无关错误仍然导致失败，并单独报告耗尽情况。未知的重置时间报告为 unknown；单独的池化 REST 配额并不是身份请求失败的证据。刷新凭据不会恢复配额。只有缺失或被拒绝的认证才提示手动配置或刷新预期使用的活动凭据；forbidden（禁止）、服务器、传输和格式错误的响应仍然是阻塞性失败，不提供登录建议。预检不会重试、切换账户或更改 GitHub CLI 路由，也不会打印原始响应体、响应头或 CLI 错误。
默认的 rollup 模式会等待所附的 CI 工作流成功，并等待其余 rollup 检查无失败地完成。同名检查在同一工作流和事件内使用 GitHub CLI 风格的去重；这并不确立 GitHub 服务器的合并授权。Auto response 被排除在等待之外。默认模式会排除仅与另一个 PR 关联的运行。替换整个较旧的作业图需要两个运行都能唯一标识所请求的 PR 和 head，并带有匹配的工作流、事件和检查套件证据。仅凭共享的 head SHA 是不够的，因为不同的 PR 基础分支可以选择不同的作业。没有该证据时，唯一作业（包括已取消的作业）仍然可见。对于 pull_request_target 图，监视器没有与 PR 绑定的替换证据，因此它们的唯一作业也仍然可见。在监视所附运行期间，缺失或歧义的 PR 关联会阻止整图替换；同名、同事件的去重仍然适用于共享的 head SHA。替换证据会解析 rollup 引用的较旧运行 ID，包括初始附加页面之外的运行。元数据在作业和轮询之间复用；缺失的记录会在监视器的截止时间内读取，随后在决策前重新观察 PR 和 rollup。每次轮询最多读取 32 条缺失的运行记录；多余的引用保持待处理，并在下次轮询时从缓存恢复。已知缺失或外部关联仍然保持阻塞，独立的失败检查也是如此。
STATUS 行报告进度。在 rollup 模式下，rollup 是有效的检查判定，github_rollup 是 GitHub 的原始聚合。被取代的检查可能使 github_rollup=FAILURE 保持，而 rollup=pending 或 rollup=green。绿色 rollup 仍会等待所附 CI 运行成功。终止状态 GREEN 以退出码 0 退出，FAILING 以退出码 15 退出，TIMEOUT 以退出码 16 退出。rollup 超时包括最后的原始聚合和待处理数量；ci-run 超时标识该完成模式，因为它不检查 rollup。
普通的主动 CI 轮询获取聚合和全局计数，而不加载检查节点或较旧运行的元数据。github_pending 报告那些原始待处理数量，包括被取代的检查和 Auto response；不可用的数量显示为 unknown，并且永远不会确立完成。CI 成功后的失败分析和待处理检查仍然会收集完整的详细信息，并报告有效的 pending 和 superseded 数量。在返回 GREEN 之前，监视器会重新检查 PR 生命周期和 head；汇总成功还要求在观察所附运行之后，聚合仍然保持成功。
当一次轮询需要详细的失败分析时，下一次轮询可以直接请求详细信息，而不是先重复汇总查询。这只会记住查询形状：每次轮询仍然收集新的证据，在历史记录或排队作业协调期间进行的读取仍然需要新的观察。不完整的详细响应仍然保持阻塞并被重试；缺失的上下文不能被当作空的成功集合。
如果主要的 GraphQL 预算耗尽，监视器会在该次调用的其余部分切换到 REST。它会以完整且有界的分页方式收集检查运行、最新状态上下文和工作流身份，然后重新验证 PR。REST 使用更多的请求和响应数据；正常路径保留紧凑的 GraphQL 查询。在 REST 模式下，原始聚合和数量从收集到的检查中得出。缺失或歧义的工作流身份绝不允许丢弃检查，GitHub 的检查套件限制也不能悄悄地把部分列表变成绿色。当这些收集到的行显示失败时，REST 会在同一次观察中添加工作流身份，而不是再次下载检查和状态页面。次级限流、认证失败、格式错误的响应和传输错误不会触发此回退，也不会更改 CLI 的认证路由。
原生即时 squash 落地在主要 GraphQL 耗尽后也可以使用 REST。这需要明确的证据：经典分支保护不存在、生效规则不要求合并队列、必需检查与其配置的发布者匹配、经过认证的写入者具有仓库管理员访问权限以读取该策略、且确切的 PR 头有资格合并。队列、自动、管理员绕过或无法验证的策略状态仍然会阻止合并。所选传输方式在调度前记录；不确定的合并请求会通过现有的保留结果进行对账，而不会通过另一个 API 重试。
由于 REST 没有 GitHub squash 消息预览，其默认消息使用当前 PR 描述和已验证的来源署名。显式的 --body-file 继续提供经过审阅的消息，并保留必需的人工署名。通过 GitHub 的 createCommitOnBranch 发布未签名的预备提交仍然需要 GraphQL；用于已验证签名提交的现有 Git 传输方式不变。失败或不确定的发布绝不会通过回退触发另一次变更操作。
HTTP 407 代理身份验证拒绝会立即以 PROXY-AUTH-FAILED 和退出码 2 退出。重试同一命令无法续期其代理访问权限。请从一次活跃的已验证运行中启动新的监视器，或在重试前修复已配置的代理验证。其他瞬时传输故障保留有界重试行为。
GitHub 可能在汇总中保留排队的重跑占位项，同时省略同名的成功作业。监视器只有在验证了成功的精确头部尝试、其完整的同名作业组，以及直接作业证据（证明每个排队别名没有运行器或已执行步骤）之后，才会协调占位项。每次轮询最多允许 32 次直接别名查找，并且证据请求共享剩余的监视器超时时间。超出该查找预算的组将保持待处理并附带警告。在应用该证明之前，监视器会刷新 PR 头、状态和检查汇总，然后重新检查关联的运行。证明仅适用于仍然具有已验证名称和排队状态的检查。活跃的重试、无关检查以及模糊或不完整的证据仍然会阻止完成。这是对 CI 状态的观察，而不是原子合并授权。
两种监视器模式仅附加到 pull_request CI 运行。--completion ci-run 仅等待该附加工作流。调用者必须单独验证必需检查；CI 成功不会覆盖另一项必需检查。
原生 scripts/pr 合并流程会重新加载已保存的 prepare 门禁模式。托管模式（prepare 期间设置 OPENCLAW_TESTBOX=1）通过 prepare 使用的同一托管验证器重新验证预备头，包括其 24 小时新鲜度、工作流身份、尝试绑定以及现有的补丁相同重用规则。接受的托管证明直接进入必需检查验证，无需等待较旧的 PR CI。本地和 Crabbox 门禁模式保留 --completion ci-run 等待。
缺少 prepare 产物或被拒绝的托管证据会停止合并验证；已保存的模式或 JSON 报告不是证明。检查 .local/gates-hosted-checks.log，解决报告中的失败，并在其产物需要刷新时重新运行 prepare。格式错误的必需检查证据和已取消的必需检查也会停止验证。服务器强制执行的发布者绑定和最终的固定头合并请求保持不变。托管模式不添加任何绕过。
对于 squash 消息中 GitHub 预览包含过时文字的情况，请使用显式的审阅正文：scripts/pr merge-run <PR> --body-file <path>。该路径相对于调用者，原生合并拥有者在验证前会快照其常规 UTF-8 文件。空文件有效。它会保留操作者提供的文本和尾部标记，并从当前 GitHub 预览和已审阅的源提交中追加任何缺失的共同作者。此选项需要 squash 且是非队列 PR；所有审查、CI、精确头部和准入检查仍然适用。未使用该选项时，包装器从 GitHub 预览组合消息：它保留由非合并 PR 提交作者或已审阅源尾部标记支持的署名，从 PR 提交中追加预览遗漏的人类 Co-authored-by 尾部标记，并删除 GitHub 重放的机器署名（Claude、Codex、Cursor、Copilot、Amp、Trae 和 GitHub App [bot] 账户），包括在逐提交项目符号内。仍包含机器署名的已审阅正文会被拒绝，预览需要此类编辑的合并队列 PR 会在准入前停止。
merge-recover 在其必需的结果 ID 和 --confirmed-operator-recovery 之后接受相同选项。使用保留结果重复 merge-run 只会协调该结果，即使原始正文文件已被删除；它绝不会调度另一个请求或更改已接受的消息。
先恢复现有的 PR 运行¶
对于已终止的现有 PR 运行，如果已诊断出基础设施故障或取消，请优先进行一次失败作业重试，而不是发起新的完整 CI 调度：
在取消一个仅因未分配作业而卡住的运行之前，请确认这正是你拥有的、针对未改变的 PR 头的运行，没有作业正在执行，并且剩余作业没有分配运行器，也没有已执行的步骤。不要仅仅因为运行缓慢就取消活跃的工作。请等待运行变为终止状态后再重试。
读回新的尝试和所选作业：确认头部未改变，并且预期的失败或取消作业已被选中。不要仅凭命令成功就推断选择结果。之前成功的作业可能以新的作业 ID 和其原始运行器详细信息出现在新尝试中；这并不代表它们再次执行。等待所选作业和聚合门禁，然后重新检查 gh pr checks <pr-number> --required --json name,bucket,state,link。
Fork PR 重试对每个 CI 作业（包括 preflight）使用 GitHub 托管的运行器。Fork 运行无法读取基础仓库的 runner-backend 变量，因此此恢复路径不依赖该覆盖。首次尝试路由以及所选测试和检查覆盖范围保持不变。
对于确实缺失或无法恢复的附加 CI，请在可用时遵循验证器的 scripts/pr ci-dispatch <pr-number> 恢复指南。其单独的手动运行可以提供托管准备证明，但该套件中一次成功的检查不能替代 GitHub 所选的必需 PR 检查。如果原始必需检查仍处于失败或已取消状态，请恢复该次运行；不要绕过它，也不要分派另一个完整套件并期望替代其状态。
PR 上下文与证据¶
外部贡献者的 PR 会运行来自 .github/workflows/real-behavior-proof.yml 的 PR 上下文与证据门禁。该工作流会检出受信任的工作流修订版本（github.workflow_sha），并且仅评估 PR 正文；它不会执行贡献者分支中的代码。
该门禁适用于不是仓库所有者、成员、协作者或机器人的 PR 作者。当 PR 正文包含已编写的 What Problem This Solves 和 Evidence 部分时，门禁通过。证据可以是针对性测试、CI 结果、截图、录屏、终端输出、实时观察、脱敏日志或工件链接。正文提供意图和有用的验证；审查者会检查代码、测试和 CI 以评估正确性。
当检查失败时，请更新 PR 正文，而不是再推送另一个代码提交。
相关¶
本页原文 Markdown：在 AtomGit 查看·内容源自开源项目 cl/openclaw