存储模型
Mantis 使用三个存储层:- Provider image - 由 Crabbox 拥有,存储在云服务提供商账户中。 包含机器能力(Chrome/Chromium、ffmpeg、scrot、 Node/corepack/pnpm、原生构建工具)以及空的缓存目录。
- Warm lease state - 由当前 operator session 拥有。可以在 lease 有效期间保存
已登录的浏览器配置文件、
/var/cache/crabbox/pnpm,以及已准备好的源码 checkout。 - Mantis artifacts - 由 OpenClaw run 拥有。位于
.artifacts/qa-e2e/mantis/...下;GitHub Actions 会上传它们,Mantis GitHub App 会在 PR 上以内联方式评论证据。
node_modules 或 dist/ 烘焙进 provider image。
GitHub 派发
从main 运行工作流:
candidate_ref 受到限制,因为该工作流使用实时凭据:它
必须解析为当前 main 的祖先、发布标签,或 openclaw/openclaw 中一个已打开 PR 的头部提交。
该工作流会生成:
- 已上传的制品
mantis-slack-desktop-smoke-<run-id>-<attempt> - 来自 Mantis GitHub App 的内联 PR 评论
slack-desktop-smoke.png、slack-desktop-smoke.mp4slack-desktop-smoke-preview.gif、slack-desktop-smoke-change.mp4mantis-slack-desktop-smoke-summary.json、mantis-slack-desktop-smoke-report.md- 远程日志:
slack-desktop-command.log、openclaw-gateway.log、chrome.log、ffmpeg.log
<!-- mantis-slack-desktop-smoke --> 标记在原位更新。
本地 CLI
冷源代码证明:node_modules 和已构建的 dist/ 时,才使用 --hydrate-mode prehydrated;否则 Mantis 会在关闭状态下失败。
证明原生 Slack 审批 UI:
--approval-checkpoints 与 --gateway-setup 互斥。除非你传入显式的审批检查点 --scenario,否则它会运行可选加入的 slack-approval-exec-native 和 slack-approval-plugin-native 场景;其他 Slack 场景会在 VM 启动前被拒绝。Slack QA 运行器会根据其观察到的真实 Slack API 消息写入每个检查点 JSON 文件,然后远程观察器会将该消息渲染到 approval-checkpoints/<scenario>-pending.png 和 approval-checkpoints/<scenario>-resolved.png 中。如果任何检查点 JSON、消息证据、ack JSON 或渲染后的截图缺失或为空,则运行失败。
冷启动的 GitHub Actions 租约没有 Slack Web cookie,因此其浏览器捕获可能会落在 Slack 登录界面上。对于审批检查点证明,请信任渲染后的检查点图片和 Slack QA 工件,而不是 slack-desktop-smoke.png。只有当浏览器截图本身必须显示 Slack Web 时,才使用保留的热租约以及手动登录的 Slack Web 配置文件。
Hydrate 模式
GitHub Actions 总是在 VM 运行之前准备候选检出内容。其
pnpm 存储按 OS、Node 版本和 lockfile 进行缓存。VM 的
source 运行在存在时也会重用 /var/cache/crabbox/pnpm。
时间解释
mantis-slack-desktop-smoke-report.md 包含各阶段耗时:
crabbox.warmup- 云提供商启动、桌面/浏览器就绪、SSH。crabbox.inspect- 租约元数据查询。credentials.prepare- Convex 凭据租约获取。crabbox.remote_run- 同步、浏览器启动、OpenClaw 安装/构建或 水合校验、网关启动、截图和视频捕获。artifacts.copy- 从虚拟机通过 rsync 拉回。
crabbox.remote_run 可能显示
accepted。将 accepted 视为“通过但附带说明”,而不是失败场景。
如果运行很慢:
warmup占主导:预烘焙,或升级为更好的 Crabbox 提供商镜像。remote_run在source模式下占主导:使用热租约,改进 pnpm store 复用,或将机器前置条件移入提供商镜像。remote_run在prehydrated模式下占主导:远程工作区实际上并未就绪, 或者网关/浏览器/Slack 设置很慢。artifacts.copy占主导:检查视频大小和产物目录内容。
证据检查清单
一个好的 PR 评论应展示:- 场景 id 和候选 SHA
- GitHub Actions 运行 URL 和制品 URL
- 内联 approval-checkpoint 截图,或来自已登录 warm lease 的 Slack Web 截图
- 如有可用,内联动画预览
- 完整 MP4 和裁剪后的 MP4 链接
- 通过/失败状态以及报告的时间摘要
失败处理
如果工作流在 VM 运行之前就失败了,请先检查 Actions job。 常见原因包括:不受信任的candidate_ref、缺少环境密钥,或者
候选安装/构建失败。
如果 VM 运行失败但截图已拷回,请检查:
crabbox vnc ...
命令通过 VNC 打开,然后在完成后停止租约:
--lease-id 重新运行。不要把那个浏览器配置文件烘焙进 provider image 中。