CI 流水线

​

流水线概览

​

快速失败顺序

1. preflight 决定哪些 lane 实际存在。docs-scope 和 changed-scope 逻辑是此工作流中的步骤，而不是独立作业。规范化的 main 会立即开始，但其并发组一次只允许一个完整运行，并会将后续推送合并为一个最新的待处理运行。与 Node 相关的 main 推送还会在下游作业挂载 key 之前，在此处串行化唯一的依赖磁盘写入者及其大小维护；Blacksmith 可能只会让稍后的工作流运行暴露一个新提交，因此同一运行中的消费者会保留带标记检查的本地回退方案。
2. security-fast、check-*、check-additional-*、check-docs 和 skills-python 会快速失败，无需等待更重的 artifact 和平台矩阵作业。
3. build-artifacts 和区域设置检查会与快速的 Linux lane 并行。Control UI 和原生应用源代码 PR 会排除生成的区域设置快照／资源；它们串行化的刷新工作流会在后台修复并自动合并隔离的生成 PR。源代码 CI 仍会阻止过期的源清单和不安全的本地化调用。生成的 PR、手动 CI 和发布准备会强制要求完整的翻译／平台生成一致性。规范化的 release/YYYY.M.PATCH 分支可以将发布准备中的区域设置修复与其他生成的发布输出一并包含。
4. 随后会展开更重的平台和运行时 lane：checks-fast-core、checks-fast-contracts-plugins-*、checks-fast-contracts-channels-*、checks-node-*、checks-windows、macos-node、macos-swift、ios-build 和 android。
5. openclaw/ci-gate 会等待所有被选中的 lane。Preflight 和 security 必须成功；下游作业只有在清单未选中它们时才可跳过。任何失败或被取消的已选 lane 都会使聚合失败。

​

PR 上下文与证据

​

范围与路由

• CI 工作流编辑会验证 Node CI 图、工作流 lint，以及 Windows 车道（ci.yml 会执行该车道），但不会自行强制执行 iOS、Android 或 macOS 原生构建；这些平台车道仍仅针对平台源代码变更运行。
• 工作流健全性检查会对所有工作流 YAML 文件运行 actionlint 和 zizmor，运行组合操作插值守卫，以及冲突标记守卫。PR 范围的 security-fast 作业还会对变更的工作流文件运行 zizmor，以便工作流安全发现能够在主 CI 图中尽早失败。
• main 推送上的文档由独立的 Docs 工作流检查，该工作流使用与 CI 相同的 ClawHub 文档镜像，因此混合代码与文档的推送不会同时排队 CI 的 check-docs 分片。拉取请求和手动 CI 仍会在文档发生变更时从 CI 运行 check-docs。
• TUI PTY 按证明责任拆分。专用的 core-runtime-tui-pty Node 分片负责针对精确头部构建的 CLI 运行完整真实后端套件。build-artifacts 作业仅保留本地模型往返和真实 Gateway 连接 canary，因此每个产物边界都会验证构建出的启动器，而不会在构建作业中重复完整的串行套件。
• SQLite 会话生命周期仅在差异触及其直接存储／会话所有者，或嵌入式运行器中的可达会话路径时，运行构建 CLI 的迁移、重启、压缩、清理和会话 RPC 证明。专用的 check-sqlite-session-lifecycle 作业会下载 build-artifacts 生成的精确运行时；手动和发布派发在目标包含该证明时始终选择它。
• 仅涉及 CI 路由的编辑、快速任务直接运行的少量核心测试夹具，以及范围有限的插件契约辅助程序编辑会使用快速的仅 Node 清单路径：preflight、security-fast，以及变更触及的快速车道——单个 checks-fast-core CI 路由任务、两个插件契约分片，或两者。该路径会跳过构建产物、Node 22 兼容性、频道契约、完整核心分片、捆绑插件分片和额外守卫矩阵。
• Windows Node 检查仅针对 Windows 专属的进程／路径包装器、npm／pnpm／UI 运行器辅助程序、包管理器配置，以及执行该车道的 CI 工作流界面；无关的源代码、插件、安装冒烟测试和仅测试变更仍会运行 Linux Node 车道。

• 插件契约和频道契约分别作为两个加权的、由 Blacksmith 支持的分片运行，并提供标准 GitHub runner 回退。
• 核心单元快速／支持 lane 分开运行；核心运行时基础设施拆分为 process、shared、hooks、secrets，以及三个 cron 域分片。
• Auto-reply 作为平衡的 worker 运行，其 reply 子树拆分为 agent-runner、commands、dispatch、session 和 state-routing 分片。
• Agentic gateway/server（控制平面）配置拆分到 chat、auth、model、HTTP/plugin、runtime 和 startup lane，而不是等待已构建产物。
• 普通 CI 只将隔离的基础设施 include-pattern 分片打包成最多包含 64 个测试文件的确定性 bundle，从而缩减 Node 矩阵，但不会合并非隔离的 command/cron、状态化 agents-core 或 gateway/server 套件。较重的固定套件保留在 8 vCPU 上，而大多数捆绑和较低权重 lane 使用 4 vCPU。Compact-small 分箱 2、5 和 8 使用现有的 8-vCPU 容量，因为近期托管运行表明它们反复占据关键路径，而 4-vCPU 队列明显更长；路由发生在打包之后，因此组所有权、覆盖范围和现有注册数量不会改变。
• 规范仓库上的拉取请求会针对合成合并树差异重用变更测试解析器。精确变更运行一个定向 Node 作业；每个选中的测试文件都获得自己的进程，因此状态化套件隔离仍保持不变。对于工作区包、包／锁文件、共享 harness、拆分配置、重命名或删除变更、公共扩展契约变更、具有特殊分片设置的测试、部分解析或空目标、过大的路径或目标计划，以及规划器错误，规划器会将兄弟测试与导入图依赖项结合，并回退到现有的 23 作业紧凑完整套件计划。定向计划始终保留完整的已构建产物边界 gate，因为其仓库扫描器无法从导入关系推导出来。main 推送运行同一个完整紧凑套件：中间待处理推送事件可能会被合并，因此最新保留下来的运行必须验证完整集成树，而不仅是其最终单次推送差异。手动派发和发布 gate 保留完整的按名称划分的分片矩阵。紧凑打包使用托管运行均值来对常规 8-vCPU 分箱进行尾部平衡，同时保留中位接纳和 4-vCPU 条带权重，因此反复出现的慢尾可以重新平衡，而不会改变有界作业数量或打包后的 runner 建议；高方差源代码／安全组保持隔离，因此其尾部不会串行化无关组。
• 完整 Node 矩阵会首先接纳持续缓慢的串行工具、auto-reply 命令分片和广泛的 core-fast 缓存写入器。这会保持 28 作业上限，同时防止关键路径工作以及下一次运行的转换种子滑入更晚的波次。
• 三个串行 Control UI 浏览器分片会按源代码字节大小贪心打包发现的测试文件。这个零状态持续时间代理避免了 Vitest 的等文件数哈希聚类，自动考虑新增和变更文件，并在不增加 runner 的情况下保留相同的完整测试清单。
• 广泛的浏览器、QA、媒体和其他插件测试使用专用 Vitest 配置，而不是共享的插件 catch-all。Include-pattern 分片使用 CI 分片名称记录计时条目，因此 .artifacts/vitest-shard-timings.json 可以区分完整配置和过滤分片。
• Linux Node 分片作业通过上游 Actions 缓存 API 持久化 Vitest 的实验性文件系统模块缓存，Blacksmith 会在其 runner 上透明地加速该缓存。每个 CI 分片都只负责恢复，并将受保护种子解包到自己的 runner 本地根目录；分片包装器随后为并发的 Vitest 进程提供独立的实时子目录。只有不取消其他运行的每日预热器或显式派发的预热器才会保存新的不可变归档，因此拉取请求不能发布转换结果或创建每个 PR 的缓存族。预热器会在新的子进程中启动每个选中的分片／配置封装，并发数为一，同时保留其 include pattern 和环境，并复用同一个串行缓存叶节点。这会防止配置全局状态泄漏，避免将过滤分片扩展为完整配置，并保留前一个子进程生成的转换结果。转换输入指纹会清除不兼容的锁文件、包、tsconfig 和 Vitest 配置代际。受保护的写入器会扫描并清理恢复的缓存，在缓存超过 2 GiB 后将其缩减至 75%。Vitest 会对模块 ID、源内容、环境和解析后的转换配置进行哈希，因此普通的部分源代码变更会使未变更条目保持温热，而变更模块则会安全地未命中。粗粒度恢复前缀会连接不同的工作流运行；普通 Actions 缓存 LRU 和非活动淘汰会限制旧的不可变归档。
• 受信任的 Blacksmith Linux Node 作业还会从每个受支持 Node 线路的一个受保护依赖磁盘绑定 pnpm store 和 node_modules。GitHub 托管作业，包括手动派发、fork 拉取请求以及两个 UI E2E 作业的同仓库重试，则使用 Actions 缓存路径。包清单、安装设置、runner 平台和精确 Node 补丁版本不会出现在磁盘 key 中；精确运行时和安装输入指纹决定作业是复用树，还是重新安装并刷新同一磁盘。哈希前会将清单规范化。仓库拥有的 openclaw 元数据块和非安装脚本会被排除，因为 pnpm 和经过审计的直接根 hook 不会读取它们，因此运行时 schema、发布元数据、格式化以及普通测试／构建脚本编辑会保留温热依赖树；未经审计的生命周期 hook 漂移会在其源输入加入指纹契约之前安全失败。依赖、包管理器、hook 源代码和锁文件变更始终会使快照失效。匹配的指纹是必要条件但并不充分：设置过程还会检查 importer 归档和清单校验和，然后验证 postinstall 保留的、由 registry 支持的锁文件依赖是否与 Node 从其 importer 解析的包清单一致。缺少或过期的 importer 内容会回退到全新安装，而不是提供根提升内容。读取只读快照不可用的拉取请求会解除工作区绑定，并安装到 runner 本地存储，避免向无法发布的克隆执行缓慢写入。Sticky cold install 会禁用 pnpm 内部的获取重试，并从逐步预热的 store 中最多尝试三次有界的完整安装；超时仍然会失败。在内容验证的恢复或 frozen-lockfile 安装之后，设置过程会禁用 pnpm 多余的运行前依赖检查：仓库会有意清理插件本地的 node_modules，而 pnpm 会将其视为过期，并在分片展开期间通过不安全的并发隐式安装进行修复。规范 main preflight 是唯一写入者，并在每次刷新时测量 store，仅在已退役的包版本将其推高到 8 GiB 以上后运行 pnpm store prune。经过验证的温热恢复不再发布无操作快照：写入器使用 StickyDisk 的 allocation-change 模式，记录其挂载时的分配基线，只有成功的依赖捕获才会创建 runner 本地重建信号。store 清理后，preflight 会将最终整个磁盘的分配量与该基线比较，并在需要时分配一个有界 sentinel，直到绝对差值相对于 StickyDisk 的 4 KiB 阈值具有经过验证的 64 KiB 裕量。即使写入器作业完成后，Blacksmith 快照发布仍是异步的，因此在全新 key 或指纹之后的首次运行可能仍然是冷启动；后续经过内容验证的精确标记恢复才是发布验证。必需的 Blacksmith CI 作业和首次尝试的同仓库拉取请求会获得一次性克隆，因此依赖变更不会创建新磁盘、竞争快照或可能取消构建的缓存锁。
• Node 分片和构建产物作业还会通过不可变 Actions 缓存恢复 Node 的便携式磁盘编译缓存。独立的 test 和 build 命名空间会防止彼此的写入器替换归档：计划中的测试预热器拥有受保护的测试种子，而 build-artifacts 每个 UTC 日最多可以从受信任的 main 推送发布一个受保护的构建归档。PR 和普通测试作业只读取受保护快照，因此功能分支字节码不会进入共享种子，PR 流量也不会创建缓存归档。这会在不同的检出路径之间复用 Node 加载的编排代码、构建工具和外部依赖的 V8 字节码缓存，包括仅源代码图的一部分发生变化时。Vitest 子进程会禁用继承的编译缓存，因为覆盖率可以在动态配置中启用，并且当脚本从字节码反序列化时，V8 覆盖率可能失去源位置精度。
• 构建产物作业还会持久化带有内容指纹的 build-all 步骤输出。CI 自行构建的插件 SDK 声明会对完整的仓库拥有的 TypeScript／JSON 源代码图进行哈希，排除已安装和生成的目录，并在 tsdown 清除 dist 后恢复扁平声明和包桥接。文档、工作流、插件以及该图之外的其他变更可以复用声明快照；源代码变更会在导出 gate 运行前重建声明。已构建的 Doctor 插件索引证明会复用完全相同的 dist/ 输出，而不是再次调用 E2E harness 的回退 TypeScript 构建。
• 完整声明构建会将 tsdown 拆分为 AI、工作区包和统一组。每个组仅缓存声明，然后仍会在恢复这些声明之前重建运行时 JavaScript。因此，核心或插件变更只会使大型统一图失效，而工作区包变更则会保守地使每个依赖声明组失效。公共完整构建通常使用不可变 Actions 缓存；粗粒度恢复 key 为部分变更提供种子，每组内容指纹会拒绝过期数据，GitHub 的缓存配额会淘汰旧代。每周的 Node 22 lane 会在成功的 main 运行后发布一个 14 天工件，并且只恢复其不可变生产者身份解析为 main 上该工作流的工件，从而避免配额 churn，同时不允许 PR 代码写入共享缓存。Private-QA 声明从不持久化到 Actions 缓存，因为缓存命名空间不是机密边界。
• check-additional-* 会将补充边界守卫列表（scripts/run-additional-boundary-checks.mts）分成一个提示密集型分片（check-additional-boundaries-a，包括 Codex 提示快照漂移检查）和一个用于剩余条带的组合分片（check-additional-boundaries-bcd），每个分片都会并发运行独立守卫并打印每项检查的计时。包边界编译／canary 工作保持在一起，而运行时拓扑架构会与嵌入 build-artifacts 的 gateway watch 覆盖分开运行。
• 在 32-vCPU 自托管构建 runner 上，Gateway watch、频道测试和核心支持边界分片会在 build-artifacts 内的 dist/ 和 dist-runtime/ 已经构建完成后同时启动。GitHub 托管回退运行会保持 Gateway watch 串行，以避免低核心数竞争消耗其就绪期限。随后两种路径都会单独运行两个已构建的 TUI PTY 产物 canary；专用 Node 分片拥有完整的串行套件。

​

ClawSweeper 活动转发

• clawsweeper_item：用于精确的 issue 和 pull request 审查请求；
• clawsweeper_comment：用于 issue 评论中的显式 ClawSweeper 命令；
• github_activity：用于 ClawSweeper 代理可能检查的常规 GitHub 活动。

​

手动派发

gh workflow run ci.yml --ref release/YYYY.M.PATCH
gh workflow run ci.yml --ref main -f target_ref=<branch-or-sha> -f include_android=true
VALIDATION_SHA="<full-commit-sha>"
gh workflow run full-release-validation.yml --ref main \
  -f ref="$VALIDATION_SHA" \
  -f expected_sha="$VALIDATION_SHA"

​

运行器

​

运行器注册预算

​

表面棘轮

• config/env-var-count-budget.txt 限制生产源代码中 src/、packages/ 和 extensions/ 下不同 OPENCLAW_* 名称的数量（不包括测试和 QA Lab）。由 node --import tsx scripts/check-env-var-count.mts 检查。
  移除环境变量：在同一个 PR 中降低该数量。添加环境变量属于配置表面决策——请在 PR 正文中说明理由。
• docs/.generated/config-baseline.counts.json 限制 openclaw.json 架构条目按类型（核心／频道／插件）划分的数量。由 pnpm config:docs:check 检查；架构发生任何更改后，使用 pnpm config:docs:gen 重新生成。

​

本地等价命令

pnpm changed:lanes                            # 检查 origin/main...HEAD 的本地变更分支分类器
pnpm check:changed                            # 智能本地检查门禁：按边界分支对变更的格式化/typecheck/lint/guards 进行检查
pnpm check                                    # 快速本地门禁：prod tsgo + 分片 lint + 并行快速 guards
pnpm check:test-types
pnpm check:timed                              # 与上面相同的门禁，但包含各阶段耗时
pnpm build:strict-smoke
pnpm check:architecture
pnpm test:gateway:watch-regression
OPENCLAW_TUI_PTY_INCLUDE_LOCAL=1 node scripts/run-vitest.mjs run --config test/vitest/vitest.tui-pty.config.ts
pnpm test                                     # vitest 测试
pnpm test:changed                             # 便宜的智能变更 Vitest 目标
pnpm test:ui                                  # Control UI 单元/浏览器测试套件
pnpm ui:i18n:check                            # 生成的 Control UI 本地化完整性检查（发布门禁）
pnpm native:i18n:baseline                     # 更新源代码维护的原生提取清单
pnpm native:i18n:verify                       # 源清单 + Android/Apple 本地化安全检查
pnpm native:i18n:check                        # 严格的已翻译/平台生成完整性检查（发布门禁）
pnpm test:channels
pnpm test:contracts:channels
pnpm check:docs                               # docs format + lint + broken links
pnpm build                                    # build dist when CI artifact/smoke checks matter
pnpm ios:build                                # generate and build the iOS app project
pnpm ci:timings                               # summarize the latest origin/main push CI run
pnpm ci:timings:recent                        # compare recent successful main CI runs
pnpm ci:timings:trend                         # 72h main baseline; latest 12h versus prior 12h
node scripts/ci-run-timings.mjs <run-id>      # summarize wall time, queue time, and slowest jobs
node scripts/ci-run-timings.mjs --latest-main # ignore issue/comment noise and choose origin/main push CI
node scripts/ci-run-timings.mjs --recent 10   # compare recent successful main CI runs
node scripts/ci-run-timings.mjs --trend-hours 72 --compare-hours 12 --detail-runs 100 --output .artifacts/ci-timings/trend.json
pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.json
pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json
pnpm test:startup:memory
pnpm test:extensions:memory -- --json .artifacts/openclaw-performance/source/mock-provider/extension-memory.json
pnpm perf:kova:summary --report .artifacts/kova/reports/mock-provider/report.json --output .artifacts/kova/summary.md

​

OpenClaw 性能

gh workflow run openclaw-performance.yml --ref main -f profile=diagnostic -f repeat=3
gh workflow run openclaw-performance.yml --ref main -f profile=smoke -f repeat=1 -f deep_profile=true -f live_openai_candidate=true
gh workflow run openclaw-performance.yml --ref main -f target_ref=v2026.5.2 -f profile=diagnostic -f repeat=3

• mock-provider：针对本地构建运行时的 Kova 诊断场景，使用确定性的模拟 OpenAI 兼容认证。
• mock-deep-profile：针对启动、网关和 agent-turn 热点进行 CPU／heap／trace 性能分析。在计划任务中运行，或在派发时设置 deep_profile=true 运行。
• live-openai-candidate：一次真实的 OpenAI openai/gpt-5.6-luna agent turn；当 OPENAI_API_KEY 不可用时会跳过。在计划任务中运行，或在派发时设置 live_openai_candidate=true 运行。

​

完整发布验证

gh workflow run openclaw-release-publish.yml \
  --ref main \
  -f tag=vYYYY.M.PATCH-beta.N \
  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
  -f full_release_validation_run_id=<successful-full-release-validation-run-id> \
  -f full_release_validation_run_attempt=<successful-full-release-validation-run-attempt> \
  -f npm_dist_tag=beta

pnpm ci:full-release --sha <full-sha>

• beta 保留速度最快的 OpenAI/核心发布关键线路。
• stable 增加稳定版 provider/backend 集合。
• full 运行范围更广的建议性 provider/media 矩阵。

​

Live 和 E2E 分片

• native-live-src-agents 和 native-live-src-agents-zai-coding
• native-live-src-gateway-core
• 按 provider 过滤的 native-live-src-gateway-profiles 任务
• native-live-src-gateway-backends
• native-live-src-infra
• native-live-test
• native-live-extensions-a-k
• native-live-extensions-l-n
• native-live-extensions-moonshot
• native-live-extensions-openai
• native-live-extensions-o-z-other
• native-live-extensions-xai
• 拆分的音频/视频媒体分片以及按 provider 过滤的音乐分片

​

包接受

​

作业

1. resolve_package 检出 workflow_ref，解析一个 package candidate，写入 .artifacts/docker-e2e-package/openclaw-current.tgz、写入 .artifacts/docker-e2e-package/package-candidate.json，将两者作为 package-under-test artifact 上传，并在 GitHub step summary 中打印 source、workflow ref、package ref、version、SHA-256 和 profile。
2. package_integrity 下载 package-under-test artifact，并使用 scripts/check-openclaw-package-tarball.mjs 强制执行公共 package tarball 合约。
3. docker_acceptance 调用 openclaw-live-and-e2e-checks-reusable.yml，使用解析出的 package source SHA（若无则回退到 workflow_ref）以及 package_artifact_name=package-under-test。该可复用工作流会下载该 artifact，校验 tarball 清单，在需要时准备 package-digest Docker images，并针对该 package 运行所选 Docker lanes，而不是打包工作流检出内容。当某个 profile 选择多个目标 docker_lanes 时，可复用工作流会先准备 package 和共享 images 一次，然后将这些 lanes 作为并行的目标 Docker 作业分发出去，并使用唯一的 artifacts。
4. package_telegram 可选地调用 NPM Telegram Beta E2E。当 telegram_mode 不为 none 时运行；如果 Package Acceptance 已解析出 package-under-test，则安装相同的 artifact；独立的 Telegram dispatch 仍然可以安装已发布的 npm spec。
5. summary 会在 package 解析、完整性、Docker acceptance 或可选的 Telegram lane 失败时使工作流失败。advisory 输入会将 acceptance 失败降级为警告，供 advisory 调用者使用。

​

候选来源

• source=npm 仅接受 openclaw@extended-stable、openclaw@beta、openclaw@latest，或如 [email protected] 这样的精确 OpenClaw release version。用于已发布的 extended-stable、pre-release 或 stable acceptance。
• source=ref 打包一个受信任的 package_ref 分支、标签或完整 commit SHA。resolver 会获取 OpenClaw branches/tags，验证所选提交可从 repository branch history 或 release tag 到达，在 detached worktree 中安装依赖，并使用 scripts/package-openclaw-for-docker.mjs 打包。
• source=url 下载一个公共 HTTPS .tgz；package_sha256 为必需。此路径会拒绝 URL 凭据、非默认 HTTPS 端口、私有／内部／特殊用途主机名或已解析 IP，以及跳转到同一公共安全策略之外的重定向。
• source=trusted-url 从 .github/package-trusted-sources.json 中一个命名的 trusted-source policy 下载 HTTPS .tgz；package_sha256 和 trusted_source_id 为必需。仅将其用于维护者拥有的企业镜像或需要配置主机、端口、路径前缀、重定向主机或私有网络解析的私有 package 仓库。如果策略声明了 bearer auth，工作流会使用固定的 OPENCLAW_TRUSTED_PACKAGE_TOKEN secret；URL 中嵌入的凭据仍会被拒绝。
• source=artifact 从 artifact_run_id 和 artifact_name 下载一个 .tgz；package_sha256 可选，但如果是外部共享的 artifact，则应提供。

​

套件 profile

• smoke — npm-onboard-channel-agent、gateway-network、config-reload
• package — npm-onboard-channel-agent、doctor-switch、update-channel-switch、skill-install、update-corrupt-plugin、upgrade-survivor、published-upgrade-survivor、root-managed-vps-upgrade、update-restart-auth、plugins-offline、plugin-update
• product — package 集合加上实时 plugins 覆盖，替代 plugins-offline，另外还包括 mcp-channels、cron-mcp-cleanup、openai-web-search-minimal、openwebui
• full — 带有 OpenWebUI 的完整 Docker release-path chunks
• custom — 精确的 docker_lanes；当 suite_profile=custom 时必需

​

旧版兼容窗口

• dist/postinstall-inventory.json 中已知的私有 QA 条目可以指向 tarball 中未包含的文件；
• 当包未暴露该标志时，doctor-switch 可以跳过 gateway install --wrapper 持久化子用例；
• update-channel-switch 可以从 tarball 派生的 fake git fixture 中清理缺失的 pnpm patchedDependencies，并且可以记录缺失的持久化 update.channel；
• plugin smokes 可以读取旧版 install-record 位置，或接受缺失的 marketplace install-record 持久化；
• plugin-update 可以允许配置元数据迁移，同时仍要求 install record 和 no-reinstall 行为保持不变。

​

示例

# 使用产品级覆盖验证当前 beta package。
gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=npm \
  -f package_spec=openclaw@beta \
  -f suite_profile=product \
  -f telegram_mode=mock-openai

# 使用 package coverage 验证已发布的 extended-stable package。
gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=npm \
  -f package_spec=openclaw@extended-stable \
  -f suite_profile=package \
  -f telegram_mode=mock-openai

# 使用当前 harness 打包并验证一个 release branch。
gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=ref \
  -f package_ref=release/YYYY.M.PATCH \
  -f suite_profile=package \
  -f telegram_mode=mock-openai

# 验证一个 tarball URL。对于 source=url，SHA-256 是必需的。
gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=url \
  -f package_url=https://example.com/openclaw-current.tgz \
  -f package_sha256=<64-char-sha256> \
  -f suite_profile=smoke

# 从命名的受信任私有镜像策略验证一个 tarball。
gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=trusted-url \
  -f trusted_source_id=enterprise-artifactory \
  -f package_url=https://packages.example.internal:8443/artifactory/openclaw/openclaw-current.tgz \
  -f package_sha256=<64-char-sha256> \
  -f suite_profile=smoke

# 重用由另一次 Actions 运行上传的 tarball。
gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=artifact \
  -f artifact_run_id=<run-id> \
  -f artifact_name=package-under-test \
  -f suite_profile=custom \
  -f docker_lanes='install-e2e plugin-update'

​

安装烟测

• 根 Dockerfile 烟测镜像会针对每个目标 SHA 只构建一次，并绑定到工作流修订版和生成者尝试，作为不可变制品保存；随后由 CLI 烟测、代理删除共享工作区的 CLI 烟测、容器网关网络 E2E，以及带有 matrix 插件的捆绑 build-arg 烟测加载。插件烟测会验证运行时依赖安装镜像行为，并确认插件加载时没有 entry-escape 诊断信息。
• QR 包安装以及安装器／更新 Docker 烟测（包括 Rocky Linux 安装器通道和针对可配置 update_baseline_version npm 基线的更新通道）会作为独立作业运行，因此安装器相关工作不会排在根镜像烟测后面等待。

​

本地 Docker 端到端测试

• 一个裸的 Node/Git 运行器，用于 installer/update/plugin-dependency 这些 lane；
• 一个功能性镜像，将同一个 tarball 安装到 /app 中，用于普通功能 lane。

​

可调参数

​

可复用的 live/E2E 工作流

​

Release-path 分块

• OPENCLAW_DOCKER_ALL_PROFILE=release-path
• OPENCLAW_DOCKER_ALL_CHUNK=core | package-update-openai | package-update-anthropic | package-update-core | plugins-runtime-plugins | plugins-runtime-services | plugins-runtime-install-a..h | openwebui

pnpm test:docker:rerun <run-id>      # 下载 Docker 工件并打印合并的/按 lane 定向的重跑命令
pnpm test:docker:timings <summary>   # 慢 lane 和阶段关键路径摘要

​

插件预发布

​

QA 实验室

• QA-Lab - All Lanes 工作流每晚在 main 上运行，也支持手动触发；它会分发运行模拟一致性检查，以及实时的 Matrix、Telegram、Discord、WhatsApp 和 Slack 作业。实时作业使用 qa-live-shared 环境；Telegram、Discord、WhatsApp 和 Slack 使用 Convex 租约，而 Matrix 会配置一次性本地凭据。
• 发布版 Matrix 目录验证会在配备 16 个 vCPU 的 Blacksmith runner 上串行运行，作业预算为 90 分钟。对该超时时间、runner 规格或并发设置的更改，都需要匹配的工作流防护措施和精确候选版本的发布证明。

​

CodeQL

​

安全类别

​

平台特定的安全分片

• CodeQL Android Critical Security — 定时 Android 安全分片。它在工作流可接受的最小 Blacksmith Linux runner 上手动构建 Android 应用以供 CodeQL 使用。产物上传到 /codeql-critical-security/android。
• CodeQL macOS Critical Security — 每周/手动 macOS 安全分片。它在 Blacksmith macOS 上手动构建 macOS 应用供 CodeQL 使用，从上传的 SARIF 中过滤掉依赖构建结果，并上传到 /codeql-critical-security/macos。之所以不放在每日默认项中，是因为即使在干净状态下，macOS 构建也会主导运行时间。

​

关键质量类别

profile=all|agent-runtime-boundary|config-boundary|core-auth-secrets|channel-runtime-boundary|gateway-runtime-boundary|memory-runtime-boundary|mcp-process-runtime-boundary|network-runtime-boundary|plugin-boundary|plugin-sdk-package-contract|plugin-sdk-reply-runtime|provider-runtime-boundary|session-diagnostics-boundary

​

维护工作流

​

文档代理

​

测试性能代理

​

合并后的重复 PR

gh workflow run duplicate-after-merge.yml \
  -f landed_pr=70532 \
  -f duplicate_prs='70530,70592' \
  -f apply=true

​

本地检查门和变更路由

​

配置基线计数棘轮

• 核心生产变更运行核心生产和核心测试类型检查，以及核心 lint/guards；
• 仅核心测试变更只运行核心测试类型检查，以及核心 lint；
• 扩展生产变更运行扩展生产和扩展测试类型检查，以及扩展 lint；
• 仅扩展测试变更只运行扩展测试类型检查，以及扩展 lint；
• 捆绑的 channel manifest、包元数据、配置 schema、UI 提示和生成器所有者还会运行捆绑 channel 配置元数据漂移检查；
• 公共 Plugin SDK 或 plugin-contract 变更会扩展到扩展类型检查，因为扩展依赖这些核心契约（Vitest 扩展全面扫描仍作为显式测试工作执行）；
• 仅发布元数据的版本提升会运行定向版本、配置和根依赖检查；
• 未知的根目录或配置变更会安全地回退到所有检查 lane。

​

Testbox 验证

pnpm crabbox:run -- --help | sed -n '1,120p'

node scripts/crabbox-wrapper.mjs run --provider blacksmith-testbox --timing-json --shell -- "pnpm test <path-or-filter>"

version="$(git -C ../crabbox describe --tags --always --dirty | sed 's/^v//')" \
  && go build -C ../crabbox -trimpath -ldflags "-s -w -X github.com/openclaw/crabbox/internal/cli.version=${version}" -o bin/crabbox ./cmd/crabbox

pnpm crabbox:run -- --provider blacksmith-testbox \
  --blacksmith-org openclaw \
  --blacksmith-workflow .github/workflows/ci-check-testbox.yml \
  --blacksmith-job check \
  --blacksmith-ref main \
  --idle-timeout 90m \
  --ttl 240m \
  --timing-json \
  --shell -- \
  "corepack pnpm check:changed"

pnpm crabbox:run -- --provider blacksmith-testbox \
  --idle-timeout 90m \
  --ttl 240m \
  --timing-json \
  --shell -- \
  "corepack pnpm test <path-or-filter>"

pnpm crabbox:run -- --provider blacksmith-testbox \
  --idle-timeout 90m \
  --ttl 240m \
  --timing-json \
  --shell -- \
  "corepack pnpm test"

blacksmith testbox list --all
blacksmith testbox status --id <tbx_id>
blacksmith testbox stop --id <tbx_id>

node scripts/crabbox-wrapper.mjs run --provider blacksmith-testbox --id <tbx_id> --timing-json --shell -- "corepack pnpm test <path-or-filter>"
pnpm crabbox:stop -- <tbx_id>

CRABBOX_CAPACITY_REGIONS=eu-west-1,eu-west-2,eu-central-1,us-east-1,us-west-2 \
  pnpm crabbox:warmup -- --provider aws --class standard --market on-demand --idle-timeout 90m
pnpm crabbox:hydrate -- --provider aws --id <cbx_id-or-slug>
pnpm crabbox:run -- --provider aws --id <cbx_id-or-slug> --timing-json --shell -- "pnpm check:changed"
pnpm crabbox:stop -- --provider aws <cbx_id-or-slug>

​

相关内容

• 安装概览
• 开发通道