跳转至

CI 流水线

CI 在 Full Release Validation 期间继续运行；遗留的 release-priority 变量不会暂停工作流准入。有关已被旧工作流修订版延期的运行，请参阅 延期的 CI 恢复。

原生视频冒烟测试覆盖率使用四个提供商的四个分片。每个提供商有十分钟的操作超时加上 30 秒测试开销；每个分片有 50 分钟的任务预算，留出八分钟用于设置。这些分片使全模式视频测试保持禁用状态。

当基于时间的拆分将超过 130 行矩阵上限时，范围广泛的 PR 保留其精简的所选所有者 Node 计划。请参阅 Node 测试通道。

本页是索引。CI 文档分布在九个页面中，每个读者任务一页。打开与您的任务匹配的页面。

完全混合扩展 lint 将相同的规范块打包到三个现有行中，在每行内共享设置和 SDK 准备。定向计划和冻结路由保留其现有布局；请参阅 runner 配置文件。

自动化准入 在 runner 分配和并发之前过滤已知的无操作事件，将自动化保留在 GitHub 托管的 runner 上。

首次尝试 PR 的 Node 矩阵使限定范围的监控器能够在取消符合条件的同仓库工作之前对失败进行分类。Fork 监控是只读的。当 PR 未更改其测试对象且所有剩余检查完成时，确切已知的每小时 main 测试失败和受支持的静态失败可以仅作参考。重试保留原生矩阵的快速失败机制。main 和手动运行保留完整矩阵。请参阅 失败取消。

第一跳兼容性使用 3,200 秒的容器预算和 3,500 秒的通道预算，基于带慢主机余量的托管 4-vCPU 测量结果。发布自升级任务允许 130 分钟用于两波六个源版本加上设置。认证更新重启使用 2,280 秒的容器预算、43 分钟的通道预算和特定通道的 1,500 秒命令超时。其 OpenAI/恢复块允许 160 分钟用于 npm 序列化通道加上设置；请参阅 发布路径块。

对于已发布升级回归门禁，请参阅 选择与路由、runner 预算 和 Package Acceptance 基线。每周验证列在 更新迁移 下。

完整的 main CI 和缓存预热 默认每小时 运行；OPENCLAW_CI_ON_PUSH=true 恢复其原有的每次推送准入。CodeQL、Workflow Sanity 和 CI 的 security-fast 保留其现有的 main 推送范围。仅更改文档的 main 推送仍跳过 CI 工作流和推送触发的缓存预热。缓存预热器独立于长构建发布依赖项，并在混合模式下维护有界的托管种子。每个被准入的规范 main 运行执行一个已发布驱动 × 候选 Docker 升级的组合；普通的手动/发布验证添加其他五个 Docker 种子通道。QA Smoke、真实 Gateway 浏览器检查和命名进程验证保留其选定的 main 覆盖率和手动/发布验证。拉取请求和精确 HEAD PR 回退调度运行静态正确性门禁、所有者限定的测试、传递导入消费者、受保护回归和六文件运行时冒烟集。Node 行以最多 150 个估算测试秒为目标。单个文件和不可分割的规范组可以超过该目标；设置、构建和队列与测试时间分开。选择沙箱容器 E2E 用例的 Node 分片会在 runner 尚未拥有 Docker 沙箱镜像时准备该镜像。缺失或无限制的运行时选择会在预检时失败，而不是回退到所有测试。Windows、浏览器、Docker、QA Smoke、打包、契约和扩展系列通过其现有所有者选择加入；单个构建进程验证具有独立的所有者标志。完整静态回退不会扩大它们。PR 豁免集成层 在每小时 main 和 Full Release Validation 中保留所测量的慢测试；当 PR 的测试或测试对象发生变化时，可选择加入。现有的 Plugin Prerelease 工作流在每小时和 Full Release Validation 中拥有完整的扩展运行时覆盖率；正常 CI 针对 PR 选择受影响的扩展所有者。Windows 在每小时 main 和普通的手动/发布验证中，跨五个测量的文件分片保留其完整清单；Windows 所有者的 PR 保留该完整清单。

每小时的 iOS 保留 ios-build (tests)，覆盖 Rust、语音、原生 Access 和聚焦的生命周期。托管附件 UI/导出、Watch 操作和 Watch 交付 UI 套件在完整的手动/发布验证中保留所有断言。Main 层模拟器构建使用原生架构，不进行索引或详细测试诊断；日志和 xcresult 包仍然可用。如果合并后的计划 iOS 运行被取消，openclaw/ci-gate 可以保持绿色，并附带通知将 iOS 验证委托给后续的计划任务；它不验证被取消的修订版，且工作流仍然可以被取消。真正的失败仍保持红色。截图捕获在其自身输入发生变化时以及完整的手动/发布验证中运行。有关覆盖率权衡，请参阅 范围选择 和 容量。

iOS 截图分片、发布资格认证、Store Release 及其仅截图操作使用 更大的托管容量。截图捕获使用标准模拟器，并一次仅创建和清理一个模拟器；仅截图操作可以在不签名或上传发布的情况下验证所选分支。配对、聊天和原生 Overview 测试保留其现有的断言和截止时间。

符合条件的 core-source 和 core-test PR 在检出中每个选定路径都存在时，使用定向类型检查。GitHub 和 hybrid 配置会将选定的消费者分布到它们现有的核心条带中；Blacksmith 配置会在中央行检查它们。所有权不明确和被删除的核心测试保留完整类型检查覆盖。

Preflight 在步骤之间以本地 JSON 文件传递完整的变更路径清单，因此大型 PR 不会因 Actions 输出或环境大小限制而丢失测试规划输入。早于该传输机制的冻结目标保留其受限的 JSON 输出契约。缺失或无效的输入仍会导致当前 PR 的 Node 规划被拒绝。

Testbox 检查工作流 为分派验证请求 Blacksmith 32 类，并默认使用四小时的外层任务预算。PR hydration 检查保留在托管 Ubuntu 上；单个测试截止时间保持不变。

完整的 GitHub 和 hybrid 类型检查独立运行五个核心条带，每个任务保留两个编译器子进程。当前的 hybrid 完整运行使用三个托管的扩展 lint 任务；定向布局保留六个条带标识。受信任的 hybrid 首次尝试会将两个打包的核心 lint 行放在 Blacksmith 16 类上，并将最终门禁放在 4 类上，以避免串行托管分配延迟。冻结目标保留其早期布局；请参阅 静态检查。

附加检查在 preflight 之后直接开始。已知的完整编译器选择会跳过发现阶段，同时在现有必需所有者中保留核心图边界；请参阅 流水线排序。

Core lint 会发现独立的 source 和 UI TypeScript 项目，保留共享的环境声明和导入的依赖。source 项目还包括 src/**/*.test-support.cjs；无关的 JavaScript 文件不会作为根添加。请参阅 本地检查。

运行时拓扑检查继承现有的 Go 内存默认值，并保留调用方覆盖和完整的架构检查序列。

Android 原生资源准备使用 Mermaid 渲染器的过滤依赖安装，包括可选的构建工具。Pnpm 保留根依赖，但省略无关的插件包；Gradle 仍会构建资源并运行选定的原生测试和 lint。历史目标保留其兼容路径。

Android 手机测试在 Blacksmith 上使用最多两个隔离的 JVM，并保留 Gradle 管理的缓存过期策略。相同的四个常规行保留第三方手机 lint 及其单元测试，以便它们复用编译和构建元数据。Wear 拥有 Wear 测试和 lint，Kotlin lint 拥有 Play/shared lint。常规同仓库 Blacksmith 运行重叠所有四个行；其他路由保留两个。所有测试和 lint 任务仍保持选中状态。

macOS Swift CI 在独立的 原生阶段 中运行应用和独立包套件，保留所有测试以及现有的并发和超时限制。

原生测试构建保留覆盖率和源码行回溯，同时省略 IDE 索引和完整的调试器类型元数据。本地开发构建保留其正常的调试设置。

短时 hybrid 任务使用 40 行基础阈值和 45 行托管准入限制，在可选工作无法容纳时保持不变的覆盖率并回退到 Blacksmith。

额外的 hybrid 检查分流需要 新近的托管分配证据。符合条件的 PR 可以转移五个已测量的检查；main 推送也可以在同一托管行限制内转移 lint 和中央类型。工件构建保留 Blacksmith，因为其已测量的托管尾部没有为 15 分钟路由目标 留出空间。

Windows 在五个 与项目对齐的已测量分片 中保留其完整的显式测试清单，用于 main 和发布验证。Windows 所有者 PR 保留完整测试族；无关 PR 省略它。

Real-Gateway 浏览器检查使用 与其选定运行器匹配的任务预算。

Control UI CI 会安装 Playwright 固定的 Chromium 修订版，即使浏览器缓存未命中。当前目标使用安装程序的 --require-playwright-chromium 模式；历史目标保留其现有安装程序。浏览器启动诊断包括 provider、page、WebSocket 和 Chromium 进程事件，用于诊断会话就绪超时，即使该超时仅在无关的单元工作完成后才报告。

浏览器扩展 CI 直接在 Node 和固定的 Bun 分支上启动已安装的、打过补丁的 Chrome MCP 依赖。

构建、QA 和测试编排会恢复相同的 受保护的 Node 编译缓存。受信任的预热器在收集测试导入之前填充构建工具，包括在 Node 和固定 Bun 分支上的相同七个 Control UI 种子文件，位于两个 Linux 缓存后端中；普通 CI 仍然只恢复。

进程内 Gateway 测试配置使用 现有打包任务中的独占计划准入。

变更所有者的 Node 行使用现有的文件/组计时证据，准入目标为 150 测试秒，并沿用现有 130 行 PR 上限。完整文件、规范配置和 worker 策略保持不变；预测的测试秒数与测量的 CI 墙钟时间相互独立。

对插件敏感的 PR 会选择其所有者测试、传递导入消费者、受保护的回归测试和策略监视。现有的 Plugin Prerelease 工作流会在每小时以及完整发布验证中保留完整的扩展覆盖；请参阅 Node 测试通道。

资源宽裕的串行 Blacksmith Node 任务使用 已测量的 Vitest worker 大小调整，并沿用现有的托管、冻结目标和重叠计划限制。

仅源代码的 Linux Node 分片可以复用受保护预热器中经内容校验的编译后 worker；固定任务准备成本 仍与测试执行和 runner 容量分开。

包含规范 E2E 测试的目标已变更分片会在启动测试子进程前，先一次性准备 private-QA 运行时。只有准备步骤成功，才会启用对预构建产物的消费，因此子进程会复用其 JavaScript、资源和新鲜度戳记，而不是再次启动完整构建。

Vitest 转换缓存指纹会排除生成的 .ci-harness 检出，因此 CI 消费方与受保护预热器会对相同的源输入进行哈希。普通 Vitest 运行仍启用 Node 字节码缓存；Vitest 本身负责 本地测试 中所述的 worker 级覆盖率保护。

转换键还包含每个项目的依赖优化器目录。当聚焦运行和完整运行共享持久缓存时，这可以防止缓存的 UI 导入混用不同项目的 Lit 实例。

Linux PR 测试在受测量的兼容单元测试通道和 Control UI Vitest 任务中使用 Bun。完整发布验证（Full Release Validation）保留其 Node 覆盖率，并同样在 Bun 上运行它们；参见 测试运行时选择。两种运行时都会按环境分批对未缓存、非隔离的 UI 文件进行分组，以减少 worker 重启，同时保留原生分片归属和 worker 预算。

冻结目标 CI 从固定的 workflow_sha 检出加载其 Node 分片规划器、规划辅助工具和测量成本。测试发现与执行仍使用候选源，因此当前分片预算不会取代发布字节。

npm/ClawHub 发布决策将普通 CI 测试、插件预发布、跨操作系统、性能与 QA 通道视为建议性记录证据。Artifact、install-smoke、survivor、所有首跳兼容性、pack/npm 资格、package-integrity 和 target-resolution 证明仍然是必需的。聚合器遵循必需输入；身份与来源验证仍然适用。

对于发布，密封清单提供 SDK 证据摘要、逐包 npm 决策以及任何已批准的 OPENCLAW_RELEASE_STABLE_SOAK_WAIVER 文本。显式发布者输入会覆盖这些默认值；历史清单保留其现有输入契约。SDK API 变更仍需要操作员提供的确认，并且密封豁免仅在仓库变量仍包含相同文本时适用。发布者仍会在变更边界验证实时权限、构建产物字节和注册表状态。

Flaky 测试绝不会阻塞 npm/ClawHub 发布：记录建议性失败并调查其负责人，无需等待绿色重跑。仅凭重放通过并不能证明修复有效。必需的构建产物、安装、更新、目标和来源证明仍会强制执行。原生应用发布与 npm/ClawHub、GitHub 最终确定和 main 收尾完全解耦；请分别报告每个平台的就绪状态。约 20 分钟的验证目标和 1 小时的发布目标，需要提供托管计时证据后方可声明。

发布收尾会使用 node --import ./scripts/tsx.mjs scripts/ci-shard-timings-refresh.mts --run <ci-child-run-id> 刷新托管的完整发布分片成本。生成器会将成功的托管任务墙钟时间（包括设置阶段）记录到现有的 config/ci-test-timings.json 存储中。发布键与精简 CI 时间跨度保持分离，并在每日重新拟合后继续存在。托管的完整规划器会在文件打包后，将超过 12 分钟的测量行拆分，同时保留确切的覆盖率和 worker 设置。完整生成的拆分代可防止后续计划重新组合高成本工作。不可拆分的超预算测试会导致规划失败，并会指名其负责人；未测量的行在声明达到 20 分钟目标之前仍需要原生计时证据。

完整发布验证的精确目标 UI 任务在两种运行时下都保留当前的三个原生分片。历史兼容性目标保留其原始的非分片包命令；参见 UI 任务预算。

设置仓库变量 OPENCLAW_RELEASE_RUNNER_GROUP，以预留一个 runner 组供完整发布验证及其构建产物、验证和可复用 worker 任务使用。Release Publish 父任务及其派发的发布子任务会读取同一变量。它仅选择该组；不会预置 runner，也不会提高并发限制。组容量不足会导致任务排队。共享工作流会从其发布调用方接收可选的 runner_group，包括来自 Release Publish 的 docker-release.yml 和 vercel-container-registry-publish.yml；docker-image-refresh.yml、普通 CI、计划性能测试以及不相关的可复用调用方保留其路由。审批和需要凭据的发布任务（npm 可信发布、ClawHub、Docker）保留其默认的 GitHub 托管标签；按小时运行的插件 npm 预览仅在 Release Publish 派发它时才路由。runner 数量、矩阵上限和默认标签不会改变。

若要在普通 PR/main 池之外预留容量：

  1. 创建一个组织 runner 组，其中的 Linux runner 标记为 ubuntu-latest/ubuntu-24.04，并包含验证所用的 Windows/macOS 标签。
  2. 授予 openclaw/openclaw 对该组的访问权限。
  3. 将 OPENCLAW_RELEASE_RUNNER_GROUP 设置为该组名称；取消设置该变量即可释放预留并恢复普通路由。

对于设置了 semantic-checks: true 的任务，Linux runner 还需要：

  • systemd 作为 PID 1 运行，并具有活动的 systemd-logind 服务。
  • 非交互式 sudo 访问权限，用于检查 logind、为 runner 用户启用 linger，并启动该用户的 systemd 管理器。
  • cgroup v2，且内存和交换空间记账已委派给用户管理器。

这些要求同样适用于自定义发布组和普通 runner。共享的设置操作会启动用户管理器，并在检查运行前验证一个真实的 64 MiB scope，该 scope 禁用交换且启用组级 OOM 终止。不支持的 runner 会在设置阶段失败；在分配验证标签之前请预置这些能力，或者取消设置发布组覆盖以恢复普通路由。设置仅用于确认后端合格；它本身不会限制后续的 lint 或编译命令。

完整发布验证在准入和复用选择之后，与制品生产者一起启动仅源码子任务。候选消费者在候选项验证完成后立即启动，同时 npm 资格验证和独立验证可以继续；参见发布流程。

由发布分发的验证子任务每个都会添加一个尽力而为的托管回执任务，每个完整活动最多七个，普通 PR/main CI 则没有。它会独立于父任务完成状态保留任务结果。当 reuse_evidence=true 时，每次分发都会检查其精确目标和输入（包括候选字节）的有界先前回执，并且只采用已验证成功的子任务。其他角色仍会分发。失败、已取消和处于活动状态的父任务都可以提供绿色子任务；当前父任务会对每个不可变选择进行封存并重新验证。发现过程不会添加任务或 Blacksmith 注册，并在未命中时回退到全新工作。

自动回复的回复测试以每个紧凑组两个工作进程的方式并行运行文件。其规划器使用独立的并行计时标识；在这些标识拥有测量值之前，串行组成本会除以有效工作进程数，单文件组则保留其完整成本。

经过测量的 Gateway 隔离/数据库工作进程队列在总内存至少为 28 GiB 的那些主机上最多使用八个工作进程；其他打包组保留其现有上限。

Commands 测试在独立文件之间共享现有工作进程预算。Doctor 会话 SQLite 用例按操作拆分，同时保留完整的修复和恢复覆盖；参见分片权重。

完整的启动语料库使用八个状态测试文件，以便现有工作进程可以共享其发布/配置矩阵。其显式回退会一次性准备运行时，并使用最多四个工作进程，受可用 CPU 并行度限制；历史冻结目标保留其遗留进程布局，并采用受 CPU 限制的准入。

页面 何时阅读
CI 流水线任务 任务表、快速失败顺序以及 Control UI 大小预算。
观察 CI 运行 等待某个拉取请求头、恢复卡住的运行，并通过证据门。
CI 检出所有权 共享检出锚点、获取重试预算以及可信操作策略。
CI 范围和路由 某个任务运行或未运行的原因：变更范围检测和手动分发。
CI 运行器类别 基于信任的运行器路由、预检和棘轮准入、Blacksmith 类别以及运行器后端模式。
CI 容量和分片权重 运行器注册、有界 PR 并发以及经过测量的分片打包。
发布验证工作流 完整发布验证、实时和 E2E 分片、包验收、安装冒烟、Docker E2E 以及插件预发布。
定时和维护工作流 OpenClaw Performance、QA Lab、CodeQL、维护任务以及 ClawSweeper 活动转发。
本地检查和 Testbox 在本地复现一条泳道、保留仅收缩棘轮，并运行 Crabbox 或 Testbox 证明。

各章节迁移位置

来自先前单页版本的每个章节标题都在此处保留其锚点，因此诸如 /ci#pipeline-overview 这样的现有链接仍然可以解析。每个条目都指向当前承载该内容的页面。

本页原文 Markdown：在 AtomGit 查看·内容源自开源项目 cl/openclaw