chore(i18n): refresh zh-CN translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
668cfb9294
commit
d29c4cc292
@ -1,57 +1,59 @@
|
||||
---
|
||||
read_when:
|
||||
- 你需要了解为什么某个 CI 作业运行了或没有运行
|
||||
- 你需要了解某个 CI 作业为什么运行或没有运行
|
||||
- 你正在调试失败的 GitHub Actions 检查
|
||||
summary: CI 作业图、作用域门禁，以及本地等效命令
|
||||
summary: CI 作业图、作用域门禁，以及本地命令对应项
|
||||
title: CI 流水线
|
||||
x-i18n:
|
||||
generated_at: "2026-04-20T14:13:24Z"
|
||||
generated_at: "2026-04-20T14:50:26Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: dd4ffb6986739ee6f4fca6e8b1f40baee7e47a8387e8d06c722881ebe78b4766
|
||||
source_hash: 69056ef80de9f1744b4a8ad71c0a8927307430defa2b8a21a8613525e9c5ac18
|
||||
source_path: ci.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# CI 流水线
|
||||
|
||||
CI 会在每次推送到 `main` 以及每个拉取请求时运行。它使用智能作用域判断，在仅有无关区域变更时跳过高开销作业。
|
||||
CI 会在每次推送到 `main` 以及每个拉取请求时运行。它使用智能作用域判断，在只有不相关区域发生变更时跳过高开销作业。
|
||||
|
||||
## 作业概览
|
||||
|
||||
| 作业 | 用途 | 运行时机 |
|
||||
| ------------------------ | ---------------------------------------------------------------------------------------- | ------------------------ |
|
||||
| `preflight` | 检测是否仅为文档变更、变更的作用域、变更的扩展，并构建 CI 清单 | 在所有非草稿推送和 PR 中始终运行 |
|
||||
| `security-fast` | 私钥检测、通过 `zizmor` 进行工作流审计、生产依赖审计 | 在所有非草稿推送和 PR 中始终运行 |
|
||||
| `build-artifacts` | 构建 `dist/` 和 Control UI 一次，并上传供下游作业复用的构建产物 | 与 Node 相关的变更 |
|
||||
| `checks-fast-core` | 快速 Linux 正确性通道，例如 bundled/plugin-contract/protocol 检查 | 与 Node 相关的变更 |
|
||||
| `checks-node-extensions` | 针对整个扩展套件运行完整的 bundled-plugin 测试分片 | 与 Node 相关的变更 |
|
||||
| `checks-node-core-test` | 核心 Node 测试分片，不包括渠道、bundled、contract 和扩展通道 | 与 Node 相关的变更 |
|
||||
| `extension-fast` | 仅针对已变更 bundled 插件的聚焦测试 | 检测到扩展变更时 |
|
||||
| `check` | CI 中的主要本地门禁：`pnpm check`、`pnpm check:test-types` 和 `pnpm build:strict-smoke` | 与 Node 相关的变更 |
|
||||
| `check-additional` | 架构、边界、导入环守卫，以及 Gateway 监视回归测试 harness | 与 Node 相关的变更 |
|
||||
| `build-smoke` | 已构建 CLI 的 smoke 测试以及启动内存 smoke 测试 | 与 Node 相关的变更 |
|
||||
| `checks` | 剩余的 Linux Node 通道：渠道测试和仅在推送时运行的 Node 22 兼容性 | 与 Node 相关的变更 |
|
||||
| `check-docs` | 文档格式、lint 和失效链接检查 | 文档发生变更 |
|
||||
| `skills-python` | 面向 Python 支持 Skills 的 Ruff + pytest | 与 Python Skills 相关的变更 |
|
||||
| `checks-windows` | Windows 专用测试通道 | 与 Windows 相关的变更 |
|
||||
| `macos-node` | 使用共享构建产物的 macOS TypeScript 测试通道 | 与 macOS 相关的变更 |
|
||||
| `macos-swift` | macOS 应用的 Swift lint、构建和测试 | 与 macOS 相关的变更 |
|
||||
| `android` | Android 构建和测试矩阵 | 与 Android 相关的变更 |
|
||||
| 作业 | 用途 | 运行时机 |
|
||||
| ------------------------ | ---------------------------------------------------------------------------------------- | ---------------------------------- |
|
||||
| `preflight` | 检测是否仅有文档变更、已变更的作用域、已变更的扩展，并构建 CI 清单 | 所有非草稿推送和 PR 都会运行 |
|
||||
| `security-fast` | 私钥检测、通过 `zizmor` 进行工作流审计、生产依赖审计 | 所有非草稿推送和 PR 都会运行 |
|
||||
| `build-artifacts` | 构建 `dist/` 和 Control UI 一次，并上传供下游作业复用的构建产物 | 与 Node 相关的变更 |
|
||||
| `checks-fast-core` | 快速 Linux 正确性通道，例如 bundled/plugin-contract/protocol 检查 | 与 Node 相关的变更 |
|
||||
| `checks-node-extensions` | 针对整个扩展套件运行完整的内置插件测试分片 | 与 Node 相关的变更 |
|
||||
| `checks-node-core-test` | Core Node 测试分片，不包括渠道、内置项、契约和扩展通道 | 与 Node 相关的变更 |
|
||||
| `extension-fast` | 仅针对已变更的内置插件运行聚焦测试 | 检测到扩展变更时 |
|
||||
| `check` | CI 中的主要本地门禁：`pnpm check`、`pnpm check:test-types` 和 `pnpm build:strict-smoke` | 与 Node 相关的变更 |
|
||||
| `check-additional` | 架构、边界、导入循环保护，以及 Gateway 网关 watch 回归测试 | 与 Node 相关的变更 |
|
||||
| `build-smoke` | 已构建 CLI 的冒烟测试和启动内存冒烟测试 | 与 Node 相关的变更 |
|
||||
| `checks` | 剩余的 Linux Node 通道：渠道测试以及仅在 push 时运行的 Node 22 兼容性检查 | 与 Node 相关的变更 |
|
||||
| `check-docs` | 文档格式、lint 和坏链检查 | 文档发生变更时 |
|
||||
| `skills-python` | 针对 Python 支持的 Skills 运行 Ruff + pytest | 与 Python Skills 相关的变更 |
|
||||
| `checks-windows` | Windows 特定测试通道 | 与 Windows 相关的变更 |
|
||||
| `macos-node` | 使用共享构建产物的 macOS TypeScript 测试通道 | 与 macOS 相关的变更 |
|
||||
| `macos-swift` | macOS 应用的 Swift lint、构建和测试 | 与 macOS 相关的变更 |
|
||||
| `android` | Android 构建和测试矩阵 | 与 Android 相关的变更 |
|
||||
|
||||
## 快速失败顺序
|
||||
|
||||
作业的排序方式是让低成本检查先失败，再运行高成本作业：
|
||||
作业的排序方式是让低成本检查先失败，避免高成本作业继续运行：
|
||||
|
||||
1. `preflight` 决定究竟存在哪些通道。`docs-scope` 和 `changed-scope` 逻辑是该作业中的步骤，不是独立作业。
|
||||
2. `security-fast`、`check`、`check-additional`、`check-docs` 和 `skills-python` 会快速失败，而不会等待更重的构建产物和平台矩阵作业。
|
||||
3. `build-artifacts` 会与快速 Linux 通道并行运行，这样下游消费者可以在共享构建就绪后立即开始。
|
||||
1. `preflight` 决定哪些通道实际存在。`docs-scope` 和 `changed-scope` 逻辑是这个作业中的步骤，不是独立作业。
|
||||
2. `security-fast`、`check`、`check-additional`、`check-docs` 和 `skills-python` 会快速失败，不需要等待更重的构建产物和平台矩阵作业。
|
||||
3. `build-artifacts` 会与快速 Linux 通道并行运行，这样下游消费者可以在共享构建准备好后立即开始。
|
||||
4. 更重的平台和运行时通道随后展开：`checks-fast-core`、`checks-node-extensions`、`checks-node-core-test`、`extension-fast`、`checks`、`checks-windows`、`macos-node`、`macos-swift` 和 `android`。
|
||||
|
||||
作用域逻辑位于 `scripts/ci-changed-scope.mjs`，并由 `src/scripts/ci-changed-scope.test.ts` 中的单元测试覆盖。
|
||||
独立的 `install-smoke` 工作流通过其自己的 `preflight` 作业复用同一个作用域脚本。它会根据更窄的 changed-smoke 信号计算 `run_install_smoke`，因此 Docker/安装 smoke 仅会在与安装、打包和容器相关的变更时运行。
|
||||
单独的 `install-smoke` 工作流会通过自己的 `preflight` 作业复用同一个作用域脚本。它会根据更窄的 changed-smoke 信号计算 `run_install_smoke`，因此 Docker/安装冒烟测试只会在与安装、打包和容器相关的变更时运行。
|
||||
|
||||
在推送时，`checks` 矩阵会增加仅在推送时运行的 `compat-node22` 通道。在拉取请求中，该通道会被跳过，矩阵会聚焦于常规测试/渠道通道。
|
||||
本地 changed-lane 逻辑位于 `scripts/changed-lanes.mjs`，并由 `scripts/check-changed.mjs` 执行。这个本地门禁在架构边界方面比宽泛的 CI 平台作用域更严格：core 生产变更会运行 core 生产 `typecheck` 加 core 测试，core 仅测试变更只运行 core 测试 `typecheck`/测试，扩展生产变更会运行扩展生产 `typecheck` 加扩展测试，扩展仅测试变更只运行扩展测试 `typecheck`/测试。公开的 Plugin SDK 或 plugin-contract 变更会扩展为扩展校验，因为扩展依赖这些 core 契约。未知的根目录/配置变更会以安全优先的方式落到所有通道。
|
||||
|
||||
在 push 时，`checks` 矩阵会添加仅在 push 时运行的 `compat-node22` 通道。在拉取请求中，这个通道会被跳过，矩阵会专注于常规测试/渠道通道。
|
||||
|
||||
## 运行器
|
||||
|
||||
@ -61,17 +63,19 @@ CI 会在每次推送到 `main` 以及每个拉取请求时运行。它使用智
|
||||
| `blacksmith-32vcpu-windows-2025` | `checks-windows` |
|
||||
| `macos-latest` | `macos-node`、`macos-swift` |
|
||||
|
||||
## 本地等效命令
|
||||
## 本地对应命令
|
||||
|
||||
```bash
|
||||
pnpm check # 快速本地门禁：生产 tsgo + 分片 lint + 并行快速守卫
|
||||
pnpm changed:lanes # 查看 origin/main...HEAD 的本地 changed-lane 分类结果
|
||||
pnpm check:changed # 智能本地门禁：按边界通道运行变更相关的 typecheck/lint/测试
|
||||
pnpm check # 快速本地门禁：生产 tsgo + 分片 lint + 并行快速保护检查
|
||||
pnpm check:test-types
|
||||
pnpm check:timed # 相同门禁，但带有各阶段耗时
|
||||
pnpm check:timed # 同一套门禁，但带每个阶段的耗时统计
|
||||
pnpm build:strict-smoke
|
||||
pnpm check:architecture
|
||||
pnpm test:gateway:watch-regression
|
||||
pnpm test # vitest 测试
|
||||
pnpm test:channels
|
||||
pnpm check:docs # 文档格式 + lint + 失效链接
|
||||
pnpm build # 当 CI 构建产物 / build-smoke 通道相关时，构建 dist
|
||||
pnpm check:docs # 文档格式 + lint + 坏链检查
|
||||
pnpm build # 当 CI 的 artifact/build-smoke 通道相关时，构建 dist
|
||||
```
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,56 +1,59 @@
|
||||
---
|
||||
read_when:
|
||||
- 运行或修复测试
|
||||
summary: 如何在本地运行测试（Vitest），以及何时使用 force / coverage 模式
|
||||
summary: 如何在本地运行测试（`vitest`），以及何时使用 force / coverage 模式
|
||||
title: 测试
|
||||
x-i18n:
|
||||
generated_at: "2026-04-20T14:13:21Z"
|
||||
generated_at: "2026-04-20T14:50:24Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 03c44e5e4fab11883d9af416141d3e8013360a46b7c201ad9ac7cee5e6b3d24e
|
||||
source_hash: 60eac73850ec1b573113a89b9f9a75079b963a1dcd0f774d96e68b08b29f221d
|
||||
source_path: reference/test.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# 测试
|
||||
|
||||
- 完整测试套件（测试套件、live、Docker）：[测试](/zh-CN/help/testing)
|
||||
- 完整测试工具包（测试套件、实时测试、Docker）：[测试](/zh-CN/help/testing)
|
||||
|
||||
- `pnpm test:force`：会终止任何仍占用默认控制端口的残留 Gateway 网关进程，然后使用隔离的 Gateway 网关端口运行完整的 Vitest 测试套件，以避免服务端测试与正在运行的实例发生冲突。当先前的 Gateway 网关运行导致端口 18789 仍被占用时，使用此命令。
|
||||
- `pnpm test:coverage`：使用 V8 覆盖率运行单元测试套件（通过 `vitest.unit.config.ts`）。全局阈值为 70% 的行/分支/函数/语句覆盖率。覆盖率会排除集成较重的入口点（CLI 接线、gateway/telegram 桥接、webchat 静态服务器），以便将目标聚焦在适合单元测试的逻辑上。
|
||||
- `pnpm test:coverage:changed`：仅对相较于 `origin/main` 已变更的文件运行单元测试覆盖率。
|
||||
- `pnpm test:changed`：当 diff 只涉及可路由的源码/测试文件时，会将已变更的 git 路径展开为有范围限制的 Vitest 通道。配置/初始化变更仍会回退到原生根项目运行，以便在需要时更广泛地重新运行接线相关测试。
|
||||
- `pnpm test`：会将显式指定的文件/目录目标路由到有范围限制的 Vitest 通道。未指定目标的运行现在会依次执行 11 个分片配置（`vitest.full-core-unit-src.config.ts`、`vitest.full-core-unit-security.config.ts`、`vitest.full-core-unit-ui.config.ts`、`vitest.full-core-unit-support.config.ts`、`vitest.full-core-support-boundary.config.ts`、`vitest.full-core-contracts.config.ts`、`vitest.full-core-bundled.config.ts`、`vitest.full-core-runtime.config.ts`、`vitest.full-agentic.config.ts`、`vitest.full-auto-reply.config.ts`、`vitest.full-extensions.config.ts`），而不是一个庞大的根项目进程。
|
||||
- 部分 `plugin-sdk` 和 `commands` 测试文件现在会通过专用的轻量通道路由，这些通道只保留 `test/setup.ts`，而运行时较重的用例仍保留在现有通道中。
|
||||
- 部分 `plugin-sdk` 和 `commands` 辅助源码文件也会将 `pnpm test:changed` 映射到这些轻量通道中的显式同级测试，因此小范围的辅助函数修改无需重新运行依赖重型运行时支持的测试套件。
|
||||
- `auto-reply` 现在也拆分为三个专用配置（`core`、`top-level`、`reply`），这样 reply 测试框架就不会压过更轻量的顶层状态/token/辅助函数测试。
|
||||
- `pnpm test:force`：终止任何仍在占用默认控制端口的残留 Gateway 网关进程，然后使用隔离的 Gateway 网关端口运行完整的 Vitest 测试套件，避免服务端测试与正在运行的实例发生冲突。当之前的 Gateway 网关运行导致端口 18789 仍被占用时，使用此命令。
|
||||
- `pnpm test:coverage`：使用 V8 覆盖率运行单元测试套件（通过 `vitest.unit.config.ts`）。全局阈值为 70% 的行 / 分支 / 函数 / 语句覆盖率。覆盖率会排除集成度较高的入口点（CLI 连接逻辑、gateway/telegram 桥接、webchat 静态服务器），以便将目标聚焦在适合进行单元测试的逻辑上。
|
||||
- `pnpm test:coverage:changed`：仅针对自 `origin/main` 以来变更的文件运行单元测试覆盖率。
|
||||
- `pnpm test:changed`：当 diff 仅涉及可路由的源码 / 测试文件时，会将变更的 git 路径展开为有作用域的 Vitest 测试通道。配置 / 设置变更仍会回退到原生根项目运行，以便在连接逻辑发生修改时进行更广泛的重跑。
|
||||
- `pnpm changed:lanes`：显示针对 `origin/main` 的 diff 所触发的架构通道。
|
||||
- `pnpm check:changed`：针对 `origin/main` 的 diff 运行智能变更检查门。它会将核心工作映射到核心测试通道，将扩展工作映射到扩展测试通道，将纯测试工作限制为仅测试类型检查 / 测试，并将公共插件 SDK 或插件契约变更扩展为扩展验证。
|
||||
- `pnpm test`：将显式的文件 / 目录目标通过有作用域的 Vitest 测试通道进行路由。未指定目标的运行现在会依次执行 11 个分片配置（`vitest.full-core-unit-src.config.ts`、`vitest.full-core-unit-security.config.ts`、`vitest.full-core-unit-ui.config.ts`、`vitest.full-core-unit-support.config.ts`、`vitest.full-core-support-boundary.config.ts`、`vitest.full-core-contracts.config.ts`、`vitest.full-core-bundled.config.ts`、`vitest.full-core-runtime.config.ts`、`vitest.full-agentic.config.ts`、`vitest.full-auto-reply.config.ts`、`vitest.full-extensions.config.ts`），而不是用一个庞大的根项目进程运行。
|
||||
- 已选定的 `plugin-sdk` 和 `commands` 测试文件现在会通过专用的轻量测试通道进行路由，这些通道仅保留 `test/setup.ts`，而运行时较重的用例仍保留在原有测试通道中。
|
||||
- 已选定的 `plugin-sdk` 和 `commands` 辅助源码文件现在也会将 `pnpm test:changed` 映射到这些轻量测试通道中的显式同级测试，因此对小型辅助文件的修改无需重新运行较重的运行时支持测试套件。
|
||||
- `auto-reply` 现在也拆分为三个专用配置（`core`、`top-level`、`reply`），这样 reply 测试框架就不会主导较轻的顶层状态 / token / helper 测试。
|
||||
- 基础 Vitest 配置现在默认使用 `pool: "threads"` 和 `isolate: false`，并在整个仓库配置中启用共享的非隔离运行器。
|
||||
- `pnpm test:channels` 运行 `vitest.channels.config.ts`。
|
||||
- `pnpm test:extensions` 运行 `vitest.extensions.config.ts`。
|
||||
- `pnpm test:extensions`：运行扩展/插件测试套件。
|
||||
- `pnpm test:perf:imports`：启用 Vitest 导入耗时 + 导入明细报告，同时仍对显式文件/目录目标使用有范围限制的通道路由。
|
||||
- `pnpm test:perf:imports:changed`：与上面相同的导入性能分析，但仅针对相较于 `origin/main` 已变更的文件。
|
||||
- `pnpm test:perf:changed:bench -- --ref <git-ref>`：针对同一组已提交 git diff，对路由后的 changed 模式路径与原生根项目运行进行基准对比。
|
||||
- `pnpm test:perf:changed:bench -- --worktree`：无需先提交，即可对当前工作树变更集进行基准测试。
|
||||
- `pnpm test:extensions`：运行扩展 / 插件测试套件。
|
||||
- `pnpm test:perf:imports`：启用 Vitest 导入耗时 + 导入明细报告，同时仍对显式文件 / 目录目标使用有作用域的测试通道路由。
|
||||
- `pnpm test:perf:imports:changed`：相同的导入性能分析，但仅针对自 `origin/main` 以来变更的文件。
|
||||
- `pnpm test:perf:changed:bench -- --ref <git-ref>`：针对同一份已提交的 git diff，将已路由的 changed 模式路径与原生根项目运行进行基准对比。
|
||||
- `pnpm test:perf:changed:bench -- --worktree`：针对当前工作区变更集进行基准测试，无需先提交。
|
||||
- `pnpm test:perf:profile:main`：为 Vitest 主线程写入 CPU profile（`.artifacts/vitest-main-profile`）。
|
||||
- `pnpm test:perf:profile:runner`：为单元测试运行器写入 CPU + 堆 profile（`.artifacts/vitest-runner-profile`）。
|
||||
- Gateway 网关集成测试：通过 `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` 或 `pnpm test:gateway` 选择性启用。
|
||||
- `pnpm test:e2e`：运行 Gateway 网关端到端冒烟测试（多实例 WS/HTTP/节点配对）。在 `vitest.e2e.config.ts` 中默认使用 `threads` + `isolate: false` 和自适应 worker；可通过 `OPENCLAW_E2E_WORKERS=<n>` 调整，并设置 `OPENCLAW_E2E_VERBOSE=1` 以输出详细日志。
|
||||
- `pnpm test:live`：运行提供商 live 测试（minimax/zai）。需要 API 密钥以及 `LIVE=1`（或提供商特定的 `*_LIVE_TEST=1`）才能取消跳过。
|
||||
- `pnpm test:docker:openwebui`：启动 Docker 化的 OpenClaw + Open WebUI，通过 Open WebUI 登录，检查 `/api/models`，然后通过 `/api/chat/completions` 运行一次真实的代理聊天。需要可用的 live 模型密钥（例如 `~/.profile` 中的 OpenAI 密钥），会拉取外部 Open WebUI 镜像，也不像常规单元测试 / e2e 测试套件那样以 CI 稳定为目标。
|
||||
- `pnpm test:docker:mcp-channels`：启动一个已预置数据的 Gateway 网关容器和第二个客户端容器，后者会启动 `openclaw mcp serve`，然后通过真实的 stdio 桥接验证路由后的会话发现、转录读取、附件元数据、实时事件队列行为、出站发送路由，以及 Claude 风格的渠道和权限通知。Claude 通知断言会直接读取原始 stdio MCP 帧，因此该冒烟测试能够反映桥接实际发出的内容。
|
||||
- Gateway 网关集成测试：通过 `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` 或 `pnpm test:gateway` 选择启用。
|
||||
- `pnpm test:e2e`：运行 Gateway 网关端到端冒烟测试（多实例 WS/HTTP/节点配对）。在 `vitest.e2e.config.ts` 中默认使用 `threads` + `isolate: false` 以及自适应 worker；可通过 `OPENCLAW_E2E_WORKERS=<n>` 调整，并设置 `OPENCLAW_E2E_VERBOSE=1` 以输出详细日志。
|
||||
- `pnpm test:live`：运行提供商实时测试（minimax/zai）。需要 API 密钥，并设置 `LIVE=1`（或提供商特定的 `*_LIVE_TEST=1`）才能取消跳过。
|
||||
- `pnpm test:docker:openwebui`：启动 Docker 化的 OpenClaw + Open WebUI，通过 Open WebUI 登录，检查 `/api/models`，然后通过 `/api/chat/completions` 运行一次真实的代理聊天。需要可用的实时模型密钥（例如 `~/.profile` 中的 OpenAI），会拉取外部 Open WebUI 镜像，并不像常规单元 / e2e 测试套件那样预期具备 CI 稳定性。
|
||||
- `pnpm test:docker:mcp-channels`：启动一个带有预置数据的 Gateway 网关容器，以及第二个会启动 `openclaw mcp serve` 的客户端容器，然后通过真实的 stdio 桥接验证路由会话发现、转录读取、附件元数据、实时事件队列行为、出站发送路由，以及 Claude 风格的渠道 + 权限通知。Claude 通知断言会直接读取原始 stdio MCP 帧，因此该冒烟测试反映的是桥接实际发出的内容。
|
||||
|
||||
## 本地 PR gate
|
||||
## 本地 PR 检查门
|
||||
|
||||
对于本地 PR 落地 / gate 检查，请运行：
|
||||
对于本地 PR 合入 / 检查，请运行：
|
||||
|
||||
- `pnpm check:changed`
|
||||
- `pnpm check`
|
||||
- `pnpm check:test-types`
|
||||
- `pnpm build`
|
||||
- `pnpm test`
|
||||
- `pnpm check:docs`
|
||||
|
||||
如果 `pnpm test` 在负载较高的主机上出现偶发失败，先重跑一次，再将其视为回归，然后用 `pnpm test <path/to/test>` 进行隔离。对于内存受限的主机，可使用：
|
||||
如果 `pnpm test` 在负载较高的主机上出现偶发失败，在将其视为回归之前请先重跑一次，然后用 `pnpm test <path/to/test>` 进行隔离。对于内存受限的主机，请使用：
|
||||
|
||||
- `OPENCLAW_VITEST_MAX_WORKERS=1 pnpm test`
|
||||
- `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/tmp/openclaw-vitest-cache pnpm test:changed`
|
||||
@ -63,9 +66,9 @@ x-i18n:
|
||||
|
||||
- `source ~/.profile && pnpm tsx scripts/bench-model.ts --runs 10`
|
||||
- 可选环境变量：`MINIMAX_API_KEY`、`MINIMAX_BASE_URL`、`MINIMAX_MODEL`、`ANTHROPIC_API_KEY`
|
||||
- 默认提示词：“Reply with a single word: ok. No punctuation or extra text.”
|
||||
- 默认提示词：“只回复一个单词：ok。不要使用标点或额外文本。”
|
||||
|
||||
上次运行（2025-12-31，20 次）：
|
||||
最近一次运行（2025-12-31，20 次）：
|
||||
|
||||
- minimax 中位数 1279ms（最小 1114，最大 2431）
|
||||
- opus 中位数 2454ms（最小 1224，最大 3170）
|
||||
@ -95,27 +98,27 @@ x-i18n:
|
||||
|
||||
- `startup`：`--version`、`--help`、`health`、`health --json`、`status --json`、`status`
|
||||
- `real`：`health`、`status`、`status --json`、`sessions`、`sessions --json`、`agents list --json`、`gateway status`、`gateway status --json`、`gateway health --json`、`config get gateway.port`
|
||||
- `all`：两个预设都包含
|
||||
- `all`：同时包含两个预设
|
||||
|
||||
输出会包含每个命令的 `sampleCount`、平均值、p50、p95、最小/最大值、exit-code/signal 分布，以及最大 RSS 摘要。可选的 `--cpu-prof-dir` / `--heap-prof-dir` 会为每次运行写入 V8 profile，这样计时和 profile 捕获就使用同一个测试框架。
|
||||
输出包括每个命令的 `sampleCount`、平均值、p50、p95、最小值 / 最大值、退出码 / 信号分布，以及最大 RSS 汇总。可选的 `--cpu-prof-dir` / `--heap-prof-dir` 会为每次运行写入 V8 profile，因此计时与 profile 捕获使用的是同一套测试框架。
|
||||
|
||||
已保存输出约定：
|
||||
保存输出约定：
|
||||
|
||||
- `pnpm test:startup:bench:smoke` 会将目标冒烟产物写入 `.artifacts/cli-startup-bench-smoke.json`
|
||||
- `pnpm test:startup:bench:save` 会使用 `runs=5` 和 `warmup=1` 将完整测试套件产物写入 `.artifacts/cli-startup-bench-all.json`
|
||||
- `pnpm test:startup:bench:update` 会使用 `runs=5` 和 `warmup=1` 刷新已检入的基线夹具 `test/fixtures/cli-startup-bench.json`
|
||||
- `pnpm test:startup:bench:update` 会使用 `runs=5` 和 `warmup=1` 刷新已纳入版本控制的基线 fixture，路径为 `test/fixtures/cli-startup-bench.json`
|
||||
|
||||
已检入的夹具：
|
||||
已纳入版本控制的 fixture：
|
||||
|
||||
- `test/fixtures/cli-startup-bench.json`
|
||||
- 使用 `pnpm test:startup:bench:update` 刷新
|
||||
- 使用 `pnpm test:startup:bench:check` 将当前结果与该夹具进行比较
|
||||
- 使用 `pnpm test:startup:bench:check` 将当前结果与该 fixture 进行比较
|
||||
|
||||
## 新手引导 E2E（Docker）
|
||||
|
||||
Docker 是可选的；只有在需要容器化的新手引导冒烟测试时才需要它。
|
||||
Docker 是可选的；仅在需要容器化新手引导冒烟测试时才需要。
|
||||
|
||||
在全新的 Linux 容器中执行完整冷启动流程：
|
||||
在干净的 Linux 容器中执行完整冷启动流程：
|
||||
|
||||
```bash
|
||||
scripts/e2e/onboard-docker.sh
|
||||
@ -123,7 +126,7 @@ scripts/e2e/onboard-docker.sh
|
||||
|
||||
该脚本会通过伪终端驱动交互式向导，验证配置 / 工作区 / 会话文件，然后启动 Gateway 网关并运行 `openclaw health`。
|
||||
|
||||
## 二维码导入冒烟测试（Docker）
|
||||
## QR 导入冒烟测试（Docker）
|
||||
|
||||
确保 `qrcode-terminal` 能在受支持的 Docker Node 运行时下加载（默认 Node 24，兼容 Node 22）：
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user