跳转至

完整发布验证

Full Release Validation 总控工作流、发布推送与 Docker Release 分发。属于发布验证工作流索引的一部分。

移动商店发布

iOS Store Release（ios-store-release.yml）与 Android Store Release（android-store-release.yml）是各自独立的手动工作流。选择 main 分支，使用默认参数点击 Run workflow 即可；无需发布参数。iOS 工作流还提供 screenshots 操作，用于仅采集截图而不执行上传。每个平台会排队各自的运行，而不会取消正在进行的上传。

这些工作流运行的命令与干净、最新的本地 main 检出中可用的相同：pnpm ios:release:upload 和 pnpm android:release:upload。两者都会冻结源提交，使用仓库版本和当前商店状态规划发布，生成平台发布说明，然后构建、签名并上传。请在本地设置 OPENAI_API_KEY；Actions 会读取该名称的仓库密钥。平台设置、签名和商店凭据记录在各应用的 fastlane/SETUP.md 中。

发布准备在受跟踪的源文件之外进行，不会创建提交或拉取请求。成功的上传记录指向 refs/openclaw/mobile-releases/ 下的原始源 SHA。Actions 会将平台计划、release-notes.json 和可用的已签名二进制文件保留 30 天。失败后，在开始另一次上传前，请检查这些工件和商店状态。App Review 提审与 Android 生产环境提升仍需手动完成。

如需在不构建或上传的情况下预览说明，请使用已保存的平台计划和新的输出路径：

pnpm mobile:release:notes -- generate --platform ios --plan /path/to/ios-plan.json --output /path/to/preview-notes.json

手机与 Wear 说明请使用 --platform android 搭配 android-plan.json。该计划标识目标版本/构建、精确的源 SHA 和公开基线构建。对于历史候选版本，请添加与该计划匹配的 --source-sha <full-commit-sha>；该提交必须存在于本地。现有输出会被验证并复用，无需调用模型。如需评估不同草稿，请使用新的输出文件。

生成过程使用 OpenAI Responses API，具备结构化输出、源证据提取和独立的事实核查。覆盖范围包括应用及捆绑的共享代码，以及 Play 特定来源和 Watch RTC。草稿必须符合商店的字符限制；生成或核查失败会停止上传。模型仍可能遗漏或误解某项变更；在手动公开推广之前，请检查运行摘要中保存的说明。说明的可复现性依赖于保留工件，而非期望新的模型请求返回完全相同的文字。

Full Release Validation

Full Release Validation 是手动发布总控工作流。每次运行都会绑定精确的 Validation SHA + Tooling SHA 元组，并在派发子工作流前拒绝 expected_sha 不匹配。Validation SHA 映射到产品验证的 Code SHA，或仅更新日志验证的 Release SHA；它不是第三个发布身份。Beta 发布映射为 release_profile=beta，且 run_release_soak=false。常规稳定版发布使用 release_profile=stable。

有关阶段矩阵、精确的工作流作业名称、配置差异、npm-beta-v1 和 npm-stable-v1 覆盖策略、工件以及定向重跑句柄，请参阅完整发布验证。

normal_ci 子工作流以精确的目标和发布范围派发 ci.yml，但不带 release_gate。仅在 FRV 中，windows-node-ci 失败以及带有已认证 recorded-flake 回执的合格作业属于参考性信息。回执绑定精确的失败作业尝试，并在清单和发布说明中保留原因及并行修复的 issue/PR。其他子工作流保持严格；覆盖、包、安装/更新和工件门禁不可被归类为 flake。请参阅记录 flake。完整活动（rerun_group=all）会保留 QA Smoke 的完整场景配置和 Control UI 性能测试，独立于变更路径。Docker seed 在每次普通的手动/发布范围中运行全部六条通道：cron-mcp-cleanup、fleet-cache、mcp-channels、mcp-code-mode-gateway、published-upgrade-survivor 和 update-channel-switch。这包括 npm-beta 和 npm-stable 资格验证。survivor 使用带 auto-auth 的 legacy-operator-state，因此已发布的驱动程序必须能够更新正在运行的托管 Gateway。每个被接纳的规范 main 运行都保留这一精确组合。冻结目标在其声明的场景目录支持 legacy-operator-state 时保留该组合；历史目标保留带 auto-auth 的 base。历史目录缺失时沿用该回退；格式错误或无效的目录会导致失败。PR 将完整 survivor 推迟到每小时 main 和 Full Release Validation，而其他 Docker seed 通道和 QA Smoke 保留其所有者映射。普通手动/发布 CI 构建完整声明完备的包。main 和选定 PR（包括精确 HEAD 的 release_gate 回退）使用现有的 ciArtifacts 配置和规范打包器，并带 --skip-build，保留运行时、公共 SDK 声明和不变的 tarball 完整性检查。每小时受保护的缓存预热任务也保留完整的声明生成。托管手动 CI 将 QA Smoke 拆分为六个部分；普通的混合模式首次尝试使用四个部分，覆盖范围相同。

对于支持测试运行时选择的目标，normal_ci 保留完整的 Node 测试清单，并在 Bun 上运行每个被接纳的 Bun 兼容选择。两个结果都是必需的；它们共享现有作业，并在每个 worker 槽位内顺序执行。不具备此能力的旧目标仅保留 Node 测试。当目标的运行时所有者接纳时，这也会包括 Control UI 配置；其 Bun 运行排除两个对 GC 敏感的文件，这些文件保留在完整 Node 运行中。较旧的仅单元测试运行时所有者保留 UI 的 Node 运行。

包验收单独保留扩展的已发布升级场景： 当前未发布候选包括原生操作者状态，且稳定/完整配置会强制 reported-issues 浸泡测试。其普通存活者重启模式和单独的 update-restart-auth 基础场景不会替代精确的 Docker 种子组合。Full Release Artifacts 和 Full Release Candidate 准备不可变的包/镜像输入；候选阶段发布检查会消费它们，而不会移动或削弱该覆盖范围。

现有冻结目标契约仍然适用：Docker 种子要求其声明的能力，没有 Docker 层级选择器的目标保留存活者回退。QA Smoke 需要受支持的测试框架，历史性能检查保留其可用性处理。聚焦重跑选择其请求的分组，已验证证据复用可以复用已完成的证明。位于剩余自动所有者路径之外，或位于五个仅发布 Docker 种子泳道中的回归，可能首先在此手动/发布层级出现。

实时/E2E 所选 ref 验证器使用稀疏检出获取完整的提交和 ref 历史。祖先关系和发布 ref 检查保持不变，而历史文件内容不进入此仅元数据作业。构建和测试作业检出各自的完整源代码树。

OpenClaw Release Publish 是手动变更发布工作流。在发布标签存在且 OpenClaw npm 预检成功后，从冻结 Tooling SHA 处的受保护轻量 release-publish/<tooling-sha12>-<epoch> 标签分发常规 beta 和 stable 发布（预检在其检查中运行 pnpm plugins:sync:check）。该标签仍选择精确的发布提交，包括 release/YYYY.M.PATCH 上的提交。对于当前验证运行，将 preflight_run_id 和 full_release_validation_run_id 设置为同一个成功的 Full Release Validation 运行 ID，并固定 full_release_validation_run_attempt。发布者从该验证清单的密封 publicationArtifacts.npmPreflight 描述符中解析独立的 Full Release Artifacts 生产者。仅生产者 ID 不携带 Full Release Validation 授权。

Docker Release 在源身份和镜像准备成功后（或提供了已准备工件）在单独作业中请求 docker-release 环境审批。审批等待保持在 docker-release-publish 之外；只有已批准的发布者进入该全局注册表/别名锁。然后它在写入前重新验证不可变源、已准备工件、证明和别名状态。Docker Hub 凭据仍然是必需的调用方提供机密。准备失败、审批拒绝和取消均不能发布。

历史恢复仍可提供单独的成功 OpenClaw NPM Release 预检运行 ID，以及匹配的成功 Full Release Validation 运行和尝试。使用发布命令创建工具标签；来自 main 的真实核心 npm、插件 npm 或 ClawHub 发布会在子分发前被拒绝。仅 Docker 恢复仍可使用 main。

发布者会为所有可发布插件包分发 Plugin NPM Release，为同一发布 SHA 分发 Plugin ClawHub Release，然后在插件 npm 成功后分发 OpenClaw NPM Release。稳定 Windows 提升是可选的：同时提供精确的 windows_node_tag 和候选批准的 windows_node_installer_digests，以在 GitHub 发布定稿后分发其签名安装程序。两者都省略以跳过 Windows。对于 npm-stable 证据，当带标签的 apps/android/version.json 与稳定标签的基础版本匹配时，一个单独的原生资格作业会为精确发布 SHA 启动启用 Android 的完整 CI。成功结果会在核心发布后重新验证，之后单独的 Android 作业才会创建其现有审批回执并分发标签拥有的 APK 工作流。这使冻结发布标签保持可用，同时不允许更窄的 npm 证据授权不合格的原生构建。原生失败仍然可见并阻止 Android 审批；核心 npm 和 GitHub 发布定稿不会等待它。整个父流程可以在核心发布后保持活动，直到原生资格完成。现有完整证据和 macOS 的独立验证保留其原生资格契约。不匹配的 Android 固定会跳过原生资格和 APK 发布，并将该固定、发布列车以及 Android 版本固定（pnpm android:version:pin -- --from-gateway）的补救措施记录在父摘要和发布证明中。聚焦的仅插件修复使用 plugin_publish_scope=selected 和非空包列表。仅插件的 all-publishable 运行需要与核心发布相同的不可变 npm 预检和 Full Release Validation 证据。

PUBLISH_REF="release-publish/<tooling-sha12>-<epoch>"
FRV_RUN_ID="<successful-full-release-validation-run-id>"
FRV_RUN_ATTEMPT="<successful-full-release-validation-run-attempt>"
gh workflow run openclaw-release-publish.yml \
  --ref "$PUBLISH_REF" \
  -f tag=vYYYY.M.PATCH-beta.N \
  -f preflight_run_id="$FRV_RUN_ID" \
  -f full_release_validation_run_id="$FRV_RUN_ID" \
  -f full_release_validation_run_attempt="$FRV_RUN_ATTEMPT" \
  -f npm_dist_tag=beta

对于快速变动分支上的固定提交证明，使用辅助命令而不是 gh workflow run ... --ref main -f ref=<sha>：

TOOLING_SHA="<recorded-full-main-ancestor-sha>"
VALIDATION_SHA="<full-release-candidate-sha>"
PUBLICATION_SELECTION='{"route":"normal","npmDistTag":"latest","publishOpenclawNpm":true,"pluginPublishScope":"all-publishable","plugins":[]}'
pnpm ci:full-release \
  --sha "$VALIDATION_SHA" \
  --target-ref release/YYYY.M.PATCH \
  --workflow-sha "$TOOLING_SHA" \
  -f validation_purpose=publish \
  -f publication_selection_json="$PUBLICATION_SELECTION"

对于 beta，选择 npmDistTag=beta；仅当目标是 prepared-button 消费者时，才选择 route=prepared。源准入验证已提交的元数据；新的发布运行在扇出之前也保留所选 npm 和 ClawHub registry 的独立准入。两者都不授予发布权限。两个契约参见 调度。对于非发布工作，显式选择 diagnostic、main-qualification 或 postpublish-confidence，并省略发布选择；profile 和 filters 仍会选择实际覆盖范围。

GitHub workflow dispatch refs 必须是分支或标签，不能是原始 commit SHA。辅助工具首先通过在新鲜的临时仓库中执行 bare-SHA fetch 来证明 GitHub 提供的是确切的 Validation SHA，包括在 dry run 中。然后，它在受信任的 Tooling SHA 处推送一个不可变的 release-ci/* workflow ref，通过 ref 和 expected_sha 传递确切的 Validation SHA，在可用时复用严格的 exact-target 证据，并验证每个子 workflow 的 headSha 都与 Tooling SHA 匹配。只记录一次该 Tooling SHA，并且永远不要从移动的 main 刷新它。常规 release 分支只接受其最终 package 版本或匹配的 beta prerelease。

release_profile 控制传入 release checks 的 live/provider 范围。手动 release workflow 默认为 stable；只有在你确实想要广泛的 provider/media 矩阵时，才使用 full。Stable 和 full release checks 始终运行详尽的 live/E2E 和 Docker release-path soak；beta profile 可以通过 run_release_soak=true 选择加入。

fail_fast 默认为 false：总控会等待每个已分派的子 workflow，并一起报告其独立失败。只有当在子 workflow 的第一个失败 job 后取消它比完整的失败清单更有用时，才设置 fail_fast=true。在 Release Checks 中，这还会启用 Matrix QA CLI 自身的第一个 scenario 取消。

  • beta 保留最快的 OpenAI/core release-critical 通道。
  • stable 增加 stable provider/backend 集合。
  • full 运行广泛的 provider/media 矩阵。

总控会记录已分派的子 run ID，并且 Verify full validation 会在该 parent 尝试期间检查它们。Parent 取消或超时会保留已采用的 exact 子 workflow 继续运行；当某个子 workflow 不再需要时，显式取消它。

对于恢复，先为每个失败测试判定 blocker 还是 flake，然后在编辑前对 product、harness/tooling/provenance、infrastructure/credential 和 wrapper 失败进行分类。只有确认的 product 失败才会改变 Code SHA。在显式的窄范围 rerun_group validation 运行之前，诊断并修复所属缺陷；永远不要自动重试失败测试，也不要扩大到 all。Flakes 最多进行两次显式的同 SHA rerun，并在 main 上跟踪修复；应记录符合条件的仍失败 job，而不是更改 tooling、重新切分或启动另一次 Full Release Validation。窄范围证据本身不是发布授权。

OpenClaw Release Checks 使用受信任的 workflow ref，将所选 ref 一次性解析为 release-package-under-test tarball，然后将该 artifact 传递给 cross-OS checks 和 Package Acceptance；当 soak 覆盖运行时，还传递给 live/E2E release-path Docker workflow。这使 package 字节在 release boxes 之间保持一致，并避免在多个子 job 中重新打包同一 candidate。对于 Codex npm-plugin live lane，release checks 会传递从 release_package_spec 派生的匹配已发布 plugin spec，传递操作员提供的 codex_plugin_spec，或者将该输入留空，以便 Docker 脚本打包所选 checkout 的 Codex plugin。

Full Release Validation 的并发以 Validation SHA、Tooling SHA、rerun group、release profile 和有效 soak 覆盖为键，并带有 cancel-in-progress: false。Release Checks 在每个阶段使用相同的覆盖标识，因此 beta、stable 和 full 请求不会相互排队。Stable/full 始终包含 soak；显式设置它们的 soak 标志不会创建另一个并发组。Parent 取消不会取消已采用的 children。

在 canonical 仓库的 hybrid runner 模式中，目标解析、证据复用、candidate 发现、candidate 绑定和 candidate 解析使用小型 Blacksmith runner 池。否则，这些串行 job 会在测试开始前累积 hosted runner 准入延迟。其他模式和非 canonical 仓库保留 GitHub-hosted runners；可复用 harness 也会遵循其显式的 hosted-runner override。长时间运行的 decision 和 diagnostic collectors 保持 hosted。

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