--- summary: "等待拉取请求头，恢复卡住的运行，并清除证据门" title: "观看 CI 跑步" read_when: - "你正在调试一个失败的 GitHub Actions 检查" - "您需要诊断故障或恢复拉取请求运行" --- ## 观看拉取请求 CI 从具有经过身份验证的 `gh` CLI 的源签出中，等待一个确切的拉取请求头： ```bash node scripts/watch-pr-ci.mjs ``` 维护者 GitHub 帮助程序在调用者未更改的 `PATH` 上使用外部 `gh`，以便路由拥有凭证、过滤和任何本机委派。 “普通”意味着规范化的终端输出：帮助程序不会发现本机安装、提取默认路由令牌或通过另一个二进制文件重试拒绝。 `OPENCLAW_GH_BIN` 是一个明确的运营商拥有的覆盖，用于支持呼叫者；仅当其身份验证和保护适当时才选择它。基于 PATH- 的读取帮助程序（包括此观察程序）会忽略该覆盖。权威 REST 使用 `Cache-Control: max-age=0` 读取请求重新验证并提供具体的存储库路径。观察程序解析其存储库一次，然后在每次读取时重新验证可变的 PR 状态。写入者身份使用经过认证的REST `GET /user --include`；包含的标头保留本机编写器路由，而不是接受中继的调用者配置文件。 在进入 PR 工作树之前，`scripts/pr` 通过一个请求检查该写入器。速率限制失败会在获取或合并副作用之前停止操作，并仅报告来自同一响应的安全元数据：HTTP 状态、配额资源、剩余配额、限制、UTC 重置时间和重试延迟（如果可用）。手动重试之前请尊重 `retry-after`；仅当预算耗尽时才等待主重置。未来的主要重置不是剩余配额的辅助限制的解锁时间。如果没有可用的重试延迟或用尽的预算重置，请等待至少 60 秒。仅零剩余余额并不会将 HTTP 200 故障归因于速率限制：格式错误或丢失的身份数据以及不相关的错误仍然会失败，并单独报告耗尽。未知重置报告为未知；单独的池 REST 配额并不是有关身份请求失败的证据。刷新凭据不会恢复配额。仅缺少或拒绝身份验证建议手动配置或刷新预期的活动凭证；禁止、服务器、传输和格式错误的响应在没有登录建议的情况下仍然会阻止失败。预检不会重试、切换帐户或更改 GitHub CLI 路由，并且不会打印原始响应正文、标头或 CLI 错误。 默认 `rollup` 模式等待附加的 CI 工作流成功，并等待剩余的汇总检查顺利完成。同名检查在工作流程和事件中使用 GitHub CLI- 风格的重复数据删除；这不会建立 GitHub 服务器合并授权。 `Auto response` 被排除在等待之外。默认模式排除仅与另一个 PR 关联的运行。替换整个旧作业图需要两次运行来唯一地识别所请求的 PR 和头，并具有匹配的工作流程、事件和检查套件证据。单独的共享头 SHA 是不够的，因为不同的 PR 基地可以选择不同的工作。独特的工作，包括取消的工作，在没有该证明的情况下仍然可见。观察者没有 `pull_request_target` 图的 PR-bound 替代证据，因此他们独特的工作也仍然可见。缺失或不明确的 PR 关联会在监控附加运行时阻止整个图替换；同名、同事件重复数据删除仍然适用于共享磁头 SHA。替换证明解析汇总引用的旧运行 ID，包括初始附件页面之外的运行。元数据在工作和民意调查中重复使用；在观察者截止日期下读取丢失的记录，然后在决定之前进行新的 PR 和汇总观察。每次轮询最多读取 32 条缺失的运行记录；多余的引用保持挂起状态，并在下次轮询时从缓存中恢复。已知的失踪或外国协会仍然处于封锁状态，独立失败的检查也是如此。 `STATUS` 行报告进度。在汇总模式下，`rollup` 是有效检查判决，`github_rollup` 是 GitHub 的原始聚合。被取代的支票可以保留 `github_rollup=FAILURE`，同时保留 `rollup=pending` 或 `rollup=green`。绿色汇总仍等待附加的 CI 运行成功。终端 `GREEN` 退出 0，`FAILING` 退出 15，`TIMEOUT` 退出 16。汇总超时包括最后的原始聚合和挂起计数； `ci-run` 超时标识该完成模式，因为它不检查汇总。 普通活动 CI 轮询会获取聚合和全局计数，而无需加载检查节点或较早运行的元数据。 `github_pending` 报告那些原始待处理计数，包括被取代的支票和 `Auto response`；不可用计数显示 `unknown` 并且从未建立完成。 CI 成功后的故障分析和挂起检查仍会收集完整的详细信息，报告有效的 `pending` 和 `superseded` 计数。在返回`GREEN`之前，观察者重新检查PR的生命周期和头部；总结成功还要求在观察附加运行后聚合保持成功。 在一次轮询需要详细的故障分析后，下一次轮询可以直接请求详细信息，而不是首先重复汇总查询。这仅记住查询形状：每次轮询仍然收集新的证据，并且在历史记录或排队作业协调期间进行的读取仍然需要新的观察。不完整的详细响应仍会被阻止并重试；缺失的上下文不能被视为空的成功集。 如果主 GraphQL 预算耗尽，则观察者将切换到 REST 来完成该调用的其余部分。它通过完整的有界分页收集检查运行、最新状态上下文和工作流程标识，然后重新验证 PR。 REST 使用更多的请求和响应数据；正常路径保留紧凑的 GraphQL 查询。在 REST 模式下，原始聚合和计数源自收集的检查。丢失或不明确的工作流程标识决不允许删除检查，并且 GitHub 的检查套件限制无法默默地将部分列表变为绿色。当这些收集的行显示失败时，REST 将工作流标识添加到同一观察中，而不是再次下载检查和状态页面。辅助限制、身份验证失败、格式错误的响应和传输错误不会触发此回退或更改 CLI 的身份验证路由。 本机立即挤压着陆也可以在初级 GraphQL 耗尽后使用 REST。这需要明确的证据证明经典分支保护不存在，有效的规则不需要合并队列，所需的检查与其配置的发布者匹配，经过身份验证的编写者具有存储库管理员访问权限来读取该策略，并且确切的 PR 头有资格合并。队列、自动、管理绕过或无法验证的策略状态仍处于阻止状态。在发货前记录所选的运输方式；不确定的合并请求通过现有保留结果进行协调，而不是通过另一个 API 重试。由于 REST 没有 GitHub 压缩消息预览，因此其默认消息使用当前的 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` 合并流重新加载保存的准备门模式。托管模式（准备期间的 `OPENCLAW_TESTBOX=1`）通过准备使用的同一托管验证器重新验证准备好的头，包括其 24 小时新鲜度、工作流身份、尝试绑定和现有补丁相同的重用规则。接受的托管证明直接进入所需检查验证，无需等待较旧的 PR CI。本地和 Crabbox 门模式保留 `--completion ci-run` 等待。 缺少准备工件或拒绝托管证据会停止合并验证；保存的模式或 JSON 报告并不能作为证据。检查 `.local/gates-hosted-checks.log`，解决报告的故障，并在其工件需要刷新时重新运行准备。格式错误的必要检查证据和取消的必要检查也会停止验证。服务器强制的发布者绑定和最终的固定头合并请求保持不变。托管模式不添加旁路。 对于一个挤压消息GitHub预览包含过时的散文，请使用明确的审阅正文`scripts/pr merge-run --body-file `。该路径是相对于调用者的，并且本机合并所有者快照其常规UTF-8验证前归档。空文件有效。它保留运营商提供的文本和预告片，附加当前缺失的合著者GitHub预览并审查源代码提交。此选项需要挤压和非队列PR；所有审查，CI、精确头和入场检查仍然适用。如果没有该选项，包装器将根据GitHub预览：它通过非合并保持信用支持PR提交作者或经过审查的源预告片，附加人类`Co-authored-by`拖车从PR的承诺省略了预览，并降低了机器信用（Claude， Codex， 光标，Copilot、安培、特雷和GitHub应用程序`[bot]`帐户）无论何处GitHub重播了它，包括每个提交项目符号内的内容。仍然包含机器信用的已审核主体被拒绝，并且合并队列PR其预览需要这样的编辑在入场前停止。 `merge-recover` 在其所需结果 ID 和 `--confirmed-operator-recovery` 后接受相同的选项。即使原始正文文件已被删除，使用保留的结果重复 `merge-run` 也只能协调该结果；它永远不会发送另一个请求或更改已接受的消息。 ### 修复本地测试失败 PR CI 运行广泛的套件直至完成，并发布一个失败表，将失败的作业与计划的 `main` CI 进行比较。运行失败后： 1. 运行 `pnpm test:ci-failed ` 以读取失败的作业、其 existing/new/unknown 之前的分类、失败的测试文件和一个本地重新运行命令。 2. 修复新故障并调查未知故障。使用 `pnpm test:ci-failed --run` 直到所选测试在本地通过。 3. 推送修复一次。让新头的PR CI 提供广泛的证明。 不要运行完整的本地套件或使用 `gh run rerun` 追逐绿色。已有故障遵循[故障表落地规则](https://github.com/openclaw/openclaw/blob/main/.agents/skills/openclaw-pr-maintainer/references/landing.md#red-main-and-inherited-failures)：匹配签名提供归属；仅作业名称匹配仍然需要将失败的测试与主要运行进行比较。桌子不放弃门。有关运行目标、非 Vitest 作业和选项，请参阅 [failed CI 测试选择](/reference/scripts/pr-tooling#rerun-failed-ci-tests)。 ### 先恢复现有的PR运行 对于在诊断基础设施故障或需要基础设施恢复的情况下运行的现有终端 PR，与新的完整 CI 调度相比，更喜欢重试失败的作业。这是确定原因后的基础设施恢复，而不是重试失败的测试以获得绿色： ```bash gh run rerun --failed --repo openclaw/openclaw ``` 在取消仅卡在未分配作业上的运行之前，请验证它是否是您为未更改的 PR 头所拥有的确切运行，没有作业正在主动执行，并且其余作业没有分配的运行程序或已执行的步骤。不要仅仅因为正在进行的工作缓慢而取消它。等待运行成为终端，然后重试。 读回新的尝试和选定的作业：确认打印头未更改，并且选择了预期失败或取消的作业。不要仅根据命令的成功来推断选择。以前成功的作业可以出现在新的尝试中，并带有新的作业 ID 及其原始运行者详细信息；这并不意味着他们再次被处决。等待选定的作业和聚合门，然后重新检查 `gh pr checks --required --json name,bucket,state,link`。 Fork PR 重试对每个 CI 作业（包括 `preflight`）使用 GitHub-hosted 运行器。 Fork 运行无法读取基础存储库的 runner-backend 变量，因此此恢复路径不依赖于该覆盖。首次尝试路由以及选定的测试和检查覆盖范围保持不变。 对于真正丢失或无法恢复的附加 CI，请遵循验证者的 `scripts/pr ci-dispatch ` 恢复指南（如果有）。其单独的手动运行可以提供托管准备证明，但该套件中的成功检查不会取代所需的 PR 检查 GitHub 选择。如果原来所需的检查仍然失败或取消，则恢复该运行；不要绕过它或派遣另一个完整套件希望取代其状态。 ## PR 上下文与证据 外部贡献者 PR 运行来自 `.github/workflows/real-behavior-proof.yml` 的 PR 上下文和证据门。工作流程检查可信工作流程修订版 （`github.workflow_sha`） 并仅评估 PR 主体；它不执行来自贡献者分支的代码。 该门控适用于 PR 作者不是仓库所有者、成员、协作者或 bot 的情况。若 PR 正文包含作者撰写的 `What Problem This Solves` 和 `Evidence` 章节，则通过。证据可以是定向测试、CI 结果、截图、录屏、终端输出、实时观察、脱敏日志或工件链接。正文提供意图和有用的验证；审阅者会检查代码、测试和 CI 以评估正确性。 当检查失败时，请更新 PR 正文，而不是再推送一次代码提交。 ## 相关内容 - [安装概览](/install) - [发布渠道](/install/development-channels)