安装冒烟与 Docker E2E

安装冒烟覆盖范围、本地 Docker E2E 聚合器及其可调参数、可复用的实时/E2E 工作流，以及发布路径分块。属于 发布验证工作流 索引的一部分。

安装冒烟¶

Install Smoke 工作流不再在拉取请求或 main 推送上运行。其夜间/手动包装器和发布验证都会调用只读的 install-smoke-reusable.yml 核心，并且每次运行都会在 GitHub 托管 runner 上执行完整的安装冒烟路径：

• 根 Dockerfile 冒烟镜像针对每个目标 SHA 构建一次，并以不可变工件的形式绑定到工作流修订版本和生产者尝试，随后由 CLI 冒烟、agents 删除共享工作区 CLI 冒烟、容器 gateway-network E2E 以及捆绑的 matrix 插件 build-arg 冒烟加载。插件冒烟会验证运行时依赖安装镜像，并确认插件加载时没有 entry-escape 诊断。
• QR 包安装以及安装器/更新 Docker 冒烟（包括 Rocky Linux 安装器泳道，以及针对可配置 update_baseline_version npm 基线的更新泳道）作为独立作业运行，因此安装器工作不会排在根镜像冒烟之后等待。

较慢的 Bun 全局安装和运行时冒烟由 run_bun_global_install_smoke 单独控制。它使用受信任的生命周期脚本安装候选版本，然后在 Bun 1.4 或更高版本下验证代表性的 CLI、local-agent 和 Gateway 路径。它在夜间计划上运行，对于来自发布检查的工作流调用默认开启，手动 Install Smoke 派发也可以选择加入。常规 PR CI 仍会为与 Node 相关的变更运行快速的 Bun launcher 回归泳道。QR 和安装器 Docker 测试保留各自专注于安装的 Dockerfile。

仅 Bun 运行时冒烟复用经过校验的候选 tarball，并使用来自 setup-test-bun 的校验和固定的 Bun fork。它在私有 mount namespace 中用记录哨兵遮蔽系统 Node，保持主机不变，并使用与子 PID 关联的 spawn 跟踪来检测安装、CLI、Gateway、node-host 配对、模拟 agent 回合、Doctor、终端和浏览器步骤中的 Node 尝试。该泳道在将 OPENCLAW_PACKAGE_BUN_LAUNCHER 设置为固定 Bun 可执行文件的情况下，进行一次无 Node 的 bun install 尝试；安装失败会使该泳道失败，而不会使用 Node 重试。安装会将其他 Node launcher 的哨兵放到 PATH 上，并让 node 不存在于安装哨兵目录中，以便 Bun 注入其生命周期 shim。在冒烟隐藏 Node 之前，Node 仍可用于 payload 准备和验证。仅 Bun 泳道仅通过其自身的 run_bun_only_runtime_smoke 输入在 Release Checks（完整发布验证）中运行，绝不在夜间计划或手动 Install Smoke 派发中运行，并跳过冻结目标。目前它是建议性的（continue-on-error）：失败会记录在运行中，但不会阻止发布。已知的 Node 要求位于 scripts/e2e/lib/bun-only-runtime/expected-node-blockers.json：未列出的 Node 尝试会失败，而不再复现的已列出 blocker 会失败，直到其条目被删除。

本地 Docker E2E¶

pnpm test:docker:all 预构建一个共享的实时测试镜像，将 OpenClaw 打包一次为 npm tarball，并构建两个共享的 scripts/e2e/Dockerfile 镜像：

• 用于安装器/更新/插件依赖泳道的裸 Node/Git runner；
• 用于常规功能泳道的功能镜像，它将同一个 tarball 安装到 /app。

Docker 泳道定义位于 scripts/lib/docker-e2e-scenarios.mts，规划器逻辑位于 scripts/lib/docker-e2e-plan.mts，runner 只执行所选计划。调度器使用 OPENCLAW_DOCKER_E2E_BARE_IMAGE 和 OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE 按泳道选择镜像，然后使用 OPENCLAW_SKIP_DOCKER_BUILD=1 运行泳道。使用这些包镜像的实时泳道不需要单独的源实时测试镜像；消费源镜像的 model/backend 泳道仍会准备它。

可调参数¶

比其有效上限更重的泳道仍可以从空池启动，然后单独运行，直到它释放容量。本地聚合器会预检 Docker，移除过期的 OpenClaw E2E 容器，输出活跃泳道状态，持久化泳道计时以进行最长优先排序，并且默认在首次失败后停止调度新的池化泳道。

可复用的实时/E2E 工作流¶

仓库 E2E 作为九个独立作业运行：四个按持续时间加权的 Gateway 分片、四个 按持续时间加权的 Control UI 分片，以及独立的 agent-plugin Gateway 测试。两个独立生产者按每个 profile 构建一次所选源： 用于 Gateway 包/类型检查的完整 private-QA 构建，以及用于 UI 和 agent-plugin 测试的 CI 工件 构建。消费者恢复精确的生产者工件， 包括生成的插件资产和本地构建元数据，并安装它们 自己的 Chromium 和 sandbox 前置条件。每组有四个测试槽位，因此长 UI 分片会一起启动，而无需等待 Gateway 声明或测试。 失败的生产者会阻塞其自身的消费者；其他诊断继续。

Gateway 分片保留现有的四个全新进程边界和两个 worker 限制。每个 UI 分片以最多两个 worker 运行其打包文件，然后串行运行其 private-server、real-Gateway 和 runtime-budget 文件。根排序器将两个项目中的文件分配到相同的四个加权分片。没有测试被过滤掉，现有的 90 分钟作业截止时间保持不变。本地 pnpm test:e2e 仍按顺序运行其套件命令；每个 UI 命令使用相同的项目策略。

这使每次调用减少七次构建，并将峰值测试并发从六提升到八。发布检查通过 gateway_repo_e2e_use_github_hosted_runners: false 将完整 Gateway 构建和四个 Gateway 测试分片路由到现有的 blacksmith-32vcpu-ubuntu-2404 profile。这使每个活动使用五个 Blacksmith 注册，同时最多有四个 Gateway 测试 runner；UI、插件和其他实时套件路由保持不变。其他调用方将 Gateway 选项默认为 true，并保留其整体托管 runner 选择。独立的 Blacksmith 调用可以注册十一个 runner：两个生产者和九个测试作业。生产者工件身份在仅消费者重试中得以保留；消费者从不按自身当前尝试次数选择工件。

可复用的实时/E2E 工作流询问 scripts/test-docker-all.mjs --plan-json 需要哪个包、镜像类型、实时镜像、泳道以及凭据覆盖。scripts/docker-e2e.mjs 随后将该计划转换为 GitHub 输出和摘要。它要么通过 scripts/package-openclaw-for-docker.mjs 打包 OpenClaw，要么下载当前运行的包工件，要么从 package_artifact_run_id 下载包工件，然后校验 tarball 清单。默认 no-push-artifact 路径通过 Blacksmith 的 Docker 层缓存构建带包摘要标签的 bare/functional 镜像，将精确的镜像字节打包为不可变工作流工件，并让每个消费者校验并加载该工件。existing-only 则要求显式的 docker_e2e_bare_image/docker_e2e_functional_image GHCR 引用，并且从不构建或推送。这些注册表拉取使用有界的每次尝试 180 秒超时，以便卡住的流快速重试，而不是消耗 CI 关键路径的大部分时间。成功完成计划验证后，openclaw-scheduled-live-checks.yml 将不可变的已测试镜像清单传递给独立的 package-write 发布者；只读 release 和 prerelease 调用方从不经过该写入器。

发布路径分块¶

发布 Docker 覆盖使用 OPENCLAW_SKIP_DOCKER_BUILD=1 运行更小的分块作业，使每个分块仅校验并加载其所需的工件支持的镜像类型（或在显式 existing-only 复用时拉取它），并通过同一加权调度器执行多个泳道：

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

当前发布 Docker 分块为 core、package-update-openai、package-update-onboarding、package-update-migrations、package-update-self-upgrade、plugins-runtime-plugins、plugins-runtime-services、从 plugins-runtime-install-a 到 plugins-runtime-install-h，以及 openwebui。package-update-openai 包含实时 Codex 插件包泳道，该泳道安装候选 OpenClaw 包，从 codex_plugin_spec 或同引用 tarball 安装 Codex 插件，并带有显式 Codex CLI 安装批准，运行 Codex CLI 预检和同会话 agent 轮次，然后运行一个零重试的中等思考轮次，该轮次发送进度、读取随机化的工作区输入、写入其精确工件并发送完成。plugins-runtime-core、plugins-runtime 和 plugins-integrations 仍保持为聚合插件/运行时别名。install-e2e 泳道别名仍然是两个 provider 安装器泳道的聚合手动重跑别名。

稳定/完整 Docker core 分块包含 live-anthropic-cache。它通过候选包的 Anthropic provider 和托管传输发送八个有界请求，在临时运行时上下文越过两个真实工具结果和随后的用户轮次时检查会话缓存复用。缺少凭据、缓存标记不正确、缓存前缀变化或重复历史写入都会使泳道失败且不重试。这补充了基于源码的实时缓存下限；它不执行 Gateway 会话调度。调度器为该泳道声明 anthropic-api-key，并且完整分块和目标泳道预检都特别要求 ANTHROPIC_API_KEY；其他支持 OAuth 凭据的 Anthropic 泳道仍接受 OAuth 凭据。

首跳兼容泳道共享 3,200 秒的内部容器预算和 3,500 秒的外部泳道预算。托管 4-vCPU 运行 36506342273 在其最终候选跳之前花费约 1,558 秒；该跳另需 560 秒，断言约需五秒，预计完整泳道约 2,125 秒。大约 1.5 倍的慢主机余量给出 3,200 秒，另加 300 秒用于主机侧工作。目标运行测量每次更新约 540–720 秒；每个泳道执行多次更新，因此这不是完整泳道时长。首跳泳道在不变的 npm 权重上限五之下权重为二，一次最多接纳两个，以减少 npm 和磁盘争用。20 分钟、权重三的幸存者可与一个首跳泳道重叠。自升级作业允许 210 分钟：三个 3,500 秒波次加上为幸存者保守预留的 20 分钟以及为设置和工件预留的 10 分钟，总计 205 分钟，向上取整。目标首跳作业保留其 60 分钟作业预算。阶段和更新步骤时长会打印在泳道日志中。

认证更新重启使用 2,280 秒容器预算和 2,580 秒（43 分钟）泳道预算：托管运行 36506342273 超过 1,515 秒，乘以大约 1.5，并另加 300 秒用于主机侧工作。其重启命令在托管运行 36506210440 中耗时 856 秒，在四核 Crabbox 上耗时 993 秒；993 × 1.5 给出泳道特定的 1,500 秒命令超时。共享的 900 秒命令默认值保持不变。package-update-openai 作业允许 160 分钟：其五个权重三的 npm 泳道在 npm 上限五之下串行执行，预算为 30 + 30 + 20 + 25 + 43 = 148 分钟。十分钟的 chat 泳道与它们重叠；设置和工件的十分钟给出 158 分钟，取整为 160。CI 的 60 分钟 docker-seed-e2e 作业不选择 update-restart-auth，因此其预算保持不变。

提供商中立的包检查以三条均衡的行运行：入门和安装切换、渠道/已发布迁移以及自升级。这避免了将八条 npm 密集型通道串行化在一个 runner 的 npm 资源限制之后。聚合的 package-update-core 和 package-update 名称仍可用于手动运行。package-update-openai 行还会运行 root 管理的 VPS 升级和经过身份验证的更新重启证明。调度器资源限制保持不变。凭据预检失败仍会阻塞，同时以下诊断池排空非实时通道；更早的设置失败和取消仍会阻止执行。

OpenWebUI 作为独立的 openwebui 块运行在专用的大磁盘 Blacksmith runner 上，每当稳定或完整发布路径覆盖请求它时，即使可复用工作流将受支持的作业路由到 GitHub 托管 runner。将外部镜像拉取单独保留，可防止大型镜像与 plugins-runtime-services 中的共享包和插件镜像竞争；旧版聚合插件/运行时块仍包含 OpenWebUI，以兼容手动重跑。捆绑渠道更新通道对临时 npm 网络故障重试一次。

每个块都会上传 .artifacts/docker-tests/，其中包含通道日志、计时、summary.json、failures.json、阶段计时、调度器计划 JSON、慢通道表格以及每个通道的重跑命令。工作流 docker_lanes 输入针对为该运行准备的镜像运行所选通道，而不是块作业，这将失败通道调试限定在一个定向 Docker 作业内；如果所选通道是实时 Docker 通道，则定向作业会为本次重跑在本地构建实时测试镜像。重跑辅助工具会验证失败工件的精确所选目标 SHA，手动 dispatch 会重新打包该 ref，因为内部可复用工作流包元组不是 workflow_dispatch schema 的一部分。生成的命令仅当这些输入由 GHCR 支持时才包含已准备的镜像输入和 shared_image_policy=existing-only；会省略 runner 本地工件标签，以便新的 runner 重新构建它们。显式目标覆盖会丢弃恢复的 GHCR 镜像 ref，除非工件证明它们与覆盖匹配。由于完整发布临时分支会被删除，工件生成的工作流定义 ref 也会被省略；除非操作员显式覆盖，否则 dispatch 使用仓库默认分支。

pnpm test:docker:rerun <run-id>      # download Docker artifacts and print combined/per-lane targeted rerun commands
pnpm test:docker:timings <summary>   # slow-lane and phase critical-path summaries

计划任务的实时/E2E 工作流每天运行完整的发布路径 Docker 套件，并在其成功后，调用显式发布者以处理精确测试的镜像工件。