Testing: updates and plugins | Fivey Can Read OpenClaw

先讲这一页到底在解决什么

Testing: updates and 新本领插件s：这回它在替你排哪颗雷

Testing: updates and 新本领插件s 像排雷图。先认症状，再找该翻哪条命令或日志，最后才决定要不要动配置，不要一上来就把整面墙都拆了。原文最响的一记鼓点，其实是：This is the dedicated checklist for update and 新本领插件 validation. The goal is simple: pr…。

原文共 9 节，先看 Start Here 路径：/help/testing-updates-plugins 查看官方原文

第一站

这组测试到底在保护什么

可以把它想成给升级包和插件做入城检查：包要完整，路要通，旧行李不能丢，坏旧件要由 doctor 明明白白修掉。

包

tarball 要完整

候选包里要有需要的 dist/postinstall-inventory.json，不能偷偷依赖仓库里没打进去的文件。

家

旧状态要保住

配置、agent、会话、workspace、插件 allowlist、频道配置，升级后都不能莫名消失。

医

旧问题交给 doctor

openclaw doctor --fix --non-interactive 负责清理旧插件状态，启动流程不应偷偷长出一堆隐藏迁移。

插

插件来源都要能走通

本地目录、git、npm、ClawHub registry，都要能按支持的方式安装、加载、更新和卸载。

第二站

本地开发先跑小门岗

改代码时先从变更相关的窄检查开始，像先查你刚动过的抽屉，不必立刻翻遍整间屋子。

先看改动影响哪些 lanes

pnpm changed:lanes --json
pnpm check:changed
pnpm test:changed

这三步像先问“我到底动了哪几块”，再跑对应检查。

插件和包清单相关改动

pnpm test src/plugins/uninstall.test.ts \
  src/infra/package-dist-inventory.test.ts \
  test/scripts/package-acceptance-workflow.test.ts

如果你碰了安装、卸载、依赖或包 inventory，就把这些守门测试也带上。

Docker lanes 用包前先验包

pnpm release:check

它会写 inventory、做 npm pack --dry-run、拒绝不该打包的文件，并试装 tarball。

第三站

Docker lanes 像把新包放进真实小房间

这些 lanes 会在 Linux 容器里安装或升级真实包，再用 CLI、Gateway、HTTP 探针和文件系统状态检查结果。

常用 focused lanes

pnpm test:docker:plugins
pnpm test:docker:plugin-lifecycle-matrix
pnpm test:docker:plugin-update
pnpm test:docker:upgrade-survivor
pnpm test:docker:published-upgrade-survivor
pnpm test:docker:update-restart-auth
pnpm test:docker:update-migration

plugins

验证插件从本地目录、file 包、git、npm、ClawHub fixture 等来源安装和更新，还会看 malformed package 是否被拒绝。

upgrade survivor

把候选包装到旧用户状态上，看配置、会话、插件和 Gateway 启动能不能一起活下来。

update migration

专门检查旧插件依赖残留、频道配置和 doctor 清理。它是清理重活，不默认塞进每次完整 release。

第四站

Package Acceptance 是 GitHub 上的包验收闸门

它先把一个候选包解析成固定 tarball，记录版本和 SHA-256，再让 Docker E2E lanes 都围着同一个包跑。这样大家检查的是同一件包裹。

npm

测已发布包

可以验证 openclaw@beta、openclaw@latest 或某个精确版本。

ref

测分支或提交

把可信 branch、tag 或 commit 打包后，交给当前 harness 检查。

url

测外部 tarball

需要 HTTPS tarball 和指定 SHA-256，确保验收的包没有被换掉。

artifact

复用构建产物

Full Release Validation 常用这个来源，直接拿已经上传的 release artifact 验收。

第五站

发版默认证明栈，从轻到重排队

发版候选不靠一个超级命令赌运气，而是像过五道门：先源代码，再包，再产品行为，再跨系统，最后按需 live。

1. 变更检查

pnpm check:changed 和 pnpm test:changed 先守住源码层回归。

2. 包完整性

pnpm release:check 确认 tarball、inventory、postinstall 和入口烟雾都正常。

3. 包验收

Package Acceptance 或 release-check package lanes 验证安装、更新、重启、插件合同。

4. 跨 OS

检查安装器、onboarding 和平台特有行为，避免只在一种系统上看起来没事。

5. Live suites

只有改动碰到 provider 或托管服务行为时，才把 live 测试接上。

第六站

旧版本兼容要窄，不要把旧包袱背到启动里

有些早期包已经发出去，验收时可以对已知历史缺口保持有限宽容。但新的包必须满足现代合同，不能继续新增“启动时偷偷修旧状态”的魔法。

正确修法

如果旧形状需要修复，优先扩展 doctor repair，然后用 upgrade-survivor、published-upgrade-survivor 或 update-restart-auth 证明它真的会修。

为什么这样做

启动流程越干净，日常运行越可预期；doctor 则像维修单，哪里修过、为什么修，都更容易追踪。

最后记住

更新和插件验证，目标是让升级像搬家清单一样可靠

小改动先跑窄测试，包要先证明自己完整，Docker lanes 负责模拟真实安装升级，Package Acceptance 负责盯住同一个候选包。这样发出去的东西，才不会让用户的旧家当散一地。