test(suite): 判据总入口 run-all —— 全部跑完再算退出码，并接上两条从未跑过的判据
## 为什么 `npm test` 是 `&&` 链：**前面红一条，后面全部不跑**。于是"只红一条"看起来像 "只有一个问题"，实际后面那些判据连跑都没跑（`packaging` 那条能发现"界面改了没重打包"的 判据，长期因此隐身）。而且这套规矩下"全绿"可信、"红"不可信。 改成 `test/run-all.mjs`（pi 建议）：每条都跑，红的收集起来最后一起报、一起退出。 - **自检 1**：清单里的文件必须存在（名字写错 = 一条判据静默消失）； - **自检 2**：`test/` 下每个 `*.test.mjs` 都必须接进清单 —— **新增判据忘了接线直接红**。 这条自检当场抓出 `nav-merge.test.mjs`、`build-stamp.test.mjs` 两个"写好了没接线"的文件 （8 + 4 条判据此前从未跑过，与 `cross-client-theme` 是同一族问题）。 - 变异验证：强制 `theme.test.mjs` 判红 → 后面 5 条判据照跑，汇总如实报"红 1/9"、退出码 1。 `package.json`：`"test": "node test/run-all.mjs && vitest run"`。 ## 接线后暴露的两条陈旧判据（代码没错、判据钉的是旧写法），按"钉行为不钉字面"修 1. `setViewMode(target || commTab` —— 代码后来等价改写成 `target ?? (isComm ? commTab : modes[0])`。改成钉行为"isComm 时落到 commTab"， 并额外要求桌面分支带 `target`（否则日历/联系人点不动）。 2. `MailView.tsx` 里 grep `glass-control` —— 授权多选胶囊已抽成共用组件 `ComposerChip`， 样式其实是对的（neutral 未选中态就是 `glass-control`）。改成钉 "MailView 用 ComposerChip" + "ComposerChip 用控件档"（文件会搬、组件不会）。 两条都做了变异验证（去掉玻璃档 / 去掉 commTab 回退 → 各判红 1 条）。 ## 生成产物再补一条判据（pi 提议） 用 postcss 真解析 `background-takeover.generated.css`：断言每条规则的选择器形状恰好是 `html[data-bg='on'] .bg-xxx`，且规则条数与源码扫到的清单条数一致。 只验"能解析"不够 —— 实测 postcss 对当年那份坏产物照样解析出 1 条规则（选择器前粘了 注释尾巴），所以卡形状与条数。变异：把坏头注释塞回生成产物 → 该条判红。 ## BUILD.md：deb 结论撤回（不是 fpm） `TMPDIR=/var/tmp/ebtmp` 在本沙箱建不出来；把 TMPDIR 指到工作区大盘后 deb 正常产出 （`release/agentmail-web_0.1.0_amd64.deb`，约 100MB）。日志关键行是 **`Errno::ENOSPC`**： fpm 要把 291MB 的 `linux-unpacked` 整份复制进 TMPDIR，而本机 `/tmp` 是 9.8G tmpfs、 被 `/tmp/gocache`（4.5G）等占到 99%。所以「本机打不出 deb」是环境症状、不是工具链缺陷， deb 不必从 `build.linux.target` 摘掉。排查命令写进 BUILD.md。 ## 验证 `npm test` 退出码 0：9 个判据文件全绿（markdown-xss、narrow-layout、nav-merge 8、 theme、background 42、cross-client 8、harmony-logic 14、build-stamp 4、packaging 3） + vitest 258/258。鸿蒙侧 `hvigorw assembleHap` 仍 BUILD SUCCESSFUL。
This commit is contained in:
@ -139,6 +139,26 @@ AGENTMAIL_USER_KEY=<用户密钥> ./agentmail-web
|
||||
|
||||
**要给用户装，优先分发 deb**：沙箱可用、依赖声明完整、可被包管理器卸载。
|
||||
|
||||
### deb 打不出来时：先看 `/tmp` 有没有空间（2026-09-14 实测）
|
||||
|
||||
本机曾以为"deb 打不出来是 fpm 的毛病"（报错停在 `fpm process failed 1`，栈顶是
|
||||
portable ruby 的 `Dir.chdir`，看着像路径权限）。**实际是 ENOSPC** —— fpm 会把
|
||||
`release/linux-unpacked`（约 291MB）**整份复制**到 `TMPDIR` 里再打包，而本机
|
||||
`/tmp` 是 9.8G 的 tmpfs 且被 `/tmp/gocache` 等占到 99%（只剩 ~100MB）：
|
||||
|
||||
```bash
|
||||
df -h /tmp # 先看这里：Avail 只剩几十 MB 就该警惕
|
||||
grep -o 'Errno::ENOSPC' <构建日志> # 真正的报错行（栈里那行只是表象）
|
||||
|
||||
# 把 TMPDIR 指到大盘上再打（工作区所在文件系统，147G 可用）
|
||||
mkdir -p "$PWD/.tmp"
|
||||
TMPDIR="$PWD/.tmp" npx electron-builder --linux deb -c.electronDownload.isVerifyChecksum=false
|
||||
# → release/agentmail-web_0.1.0_amd64.deb（约 100MB）
|
||||
```
|
||||
|
||||
结论：**不要**为了"本机打包能过"把 deb 从 `build.linux.target` 里摘掉，
|
||||
也不要改 fpm 缓存 —— 那是在改测试迁就环境。deb 是声明的交付物之一。
|
||||
|
||||
## 验证产物的方法（别只看文件存在）
|
||||
|
||||
```bash
|
||||
|
||||
@ -333,3 +333,53 @@ WebUI 侧完全不读这个字段（`mailStore` 里没有 `total`），所以这
|
||||
（给上游的可执行请求：在有人的环境里执行
|
||||
`harmony-emu start && cd client/harmony && hvigorw assembleHap && hdc install entry/build/default/outputs/default/entry-default-unsigned.hap`，
|
||||
即可让 P2a 之后所有阶段的"点击级判据"落地。）
|
||||
|
||||
### 7.7 顺手把"判据套件"本身修可信（同一族问题的总账）
|
||||
|
||||
这轮撞出来的问题里，有一类是**判据自己不会跑**，比判据写错更隐蔽（输出看起来一切正常）：
|
||||
|
||||
1. `cross-client-theme.test.mjs` 从来不在 `npm test` 链里（pi 已认领）；
|
||||
2. 有人新加的 4 条玻璃判据写在 `process.exit()` **之后** —— 一条都不执行、不计通过也不计失败；
|
||||
3. `nav-merge.test.mjs`、`build-stamp.test.mjs` 写好了**也没接线**（各 8 / 4 条判据从未跑过）；
|
||||
4. `npm test` 是 `&&` 链：**前面红一条，后面全部不跑**（`packaging` 那条因此长期隐身）。
|
||||
|
||||
改法（`test/run-all.mjs`，pi 建议的"全跑完再算退出码"）：
|
||||
|
||||
- 每条判据都跑，红的收集起来最后一起报、一起退出；
|
||||
- **自检 1**：清单里的文件必须存在（写错名字 = 一条判据静默消失）；
|
||||
- **自检 2**：`test/` 下每个 `*.test.mjs` 都必须在清单里 —— **新增判据忘了接线直接红**。
|
||||
这条自检当场就抓出上面第 3 条那两个文件。
|
||||
- 变异验证：把 `theme.test.mjs` 强制红 → 后面 5 条判据照跑，汇总如实报"红 1/9"、退出码 1。
|
||||
|
||||
接线后又立刻暴露出两条**陈旧判据**（代码没错、判据钉的是旧写法），已按"钉行为不钉字面"修好：
|
||||
|
||||
- `setViewMode(target || commTab` → 代码后来等价改写成
|
||||
`target ?? (isComm ? commTab : modes[0])`；改成钉"isComm 时落到 commTab"这个行为；
|
||||
- `MailView.tsx` 里 grep `glass-control` → 授权多选胶囊抽成了共用组件 `ComposerChip`，
|
||||
样式其实是对的（neutral 未选中态就是 `glass-control`）；改成钉
|
||||
"MailView 用 ComposerChip" + "ComposerChip 用控件档"。两条都做了变异验证（改坏必红）。
|
||||
|
||||
按 pi 的提议还给生成产物补了一条判据：用 **postcss 真解析** `background-takeover.generated.css`，
|
||||
断言**每条规则的选择器形状**都恰好是 `html[data-bg='on'] .bg-xxx` 且**规则条数与清单一致** ——
|
||||
把"生成器写坏产物"从"只有浏览器能发现"变成"跑判据就红"。
|
||||
（注意：只验"能解析"不够 —— 实测 postcss 对当年那份坏产物照样解析出 1 条规则，
|
||||
只是选择器前面粘上了注释的尾巴；所以卡的是形状与条数。）
|
||||
|
||||
套件现状：`npm test` = `node test/run-all.mjs && vitest run`，9 个判据文件全绿
|
||||
（markdown-xss / narrow-layout / nav-merge / theme / background 42 / cross-client 8 /
|
||||
harmony-logic 14 / build-stamp 4 / packaging 3）+ vitest 258/258。
|
||||
|
||||
### 7.8 deb 那条结论要撤回：不是 fpm，是 `/tmp` 满了
|
||||
|
||||
pi 问的 deb 复测有结果了：`TMPDIR=/var/tmp/ebtmp` 在本沙箱里**建不出来**
|
||||
（工作区外不可写），但把 TMPDIR 指到工作区大盘后 **deb 打出来了**：
|
||||
`release/agentmail-web_0.1.0_amd64.deb`（约 100MB）。
|
||||
|
||||
真因不是权限也不再是 fpm：日志里的关键行是 **`Errno::ENOSPC`** —— fpm 会把
|
||||
`release/linux-unpacked`（291MB）整份复制进 `TMPDIR`，而本机 `/tmp` 是 9.8G 的 tmpfs、
|
||||
被 `/tmp/gocache`（4.5G）等占到 99%（仅剩 ~100MB 可用）。
|
||||
所以「本机打不出 deb」这个结论**撤回**：它是环境症状，不是工具链缺陷，
|
||||
deb 也不必从 targets 里摘。已写进 `client/electron/BUILD.md`（含排查命令）。
|
||||
|
||||
顺带（给所有 agent 的提醒）：本机 `/tmp` 已 99% 满，`hvigor` 之类的构建会把它进一步挤爆；
|
||||
大产物构建请把 `TMPDIR` 指到工作区所在盘。
|
||||
|
||||
Reference in New Issue
Block a user