AskaEth
ae1410f342
ci: M147 给两个平台的 test 步加取证能力（--no-fail-fast + 注解 + 退出码回显）
三条红里 `test (windows)` 至今只有一个「Process completed with exit code 1」——而 cargo
自己的失败码是 101，那个 1 的来源不明（pwsh 包装层洗码 / 进程被杀，两说都未排除）。job log
要登录才能读（匿名 403），但**注解匿名可读**（GET /check-runs/<id>/annotations → 200）。
所以把一条 `cargo test --workspace --all-targets` 拆成两个平台的取证版本，各做三件事：
1. `--no-fail-fast`：cargo 默认第一个失败的 target 就停（M144 实测 Linux 只跑了 7 个 test
binary 就退），后面还有没有第二条失败完全看不到；
2. 失败时把 `error` / `failures:` / `test result: FAILED` / panicked 行升成 `::error::`
注解（`%` 转 `%25`，那是 workflow command 的保留字符）——拿不到 job log 时注解是匿名
侧唯一能取到的失败正文；
3. 显式 `echo "cargo exit=<code>"`，把「包装层把码洗成 1」「cargo 真失败（101）」「进程被杀
只给码、零诊断」三种情形分开。
两平台的码从哪来（不能混用）：
- Linux 走 bash（默认 shell 带 `-e` + `pipefail`）：先 `set +e` 再自己取 `${PIPESTATUS[0]}`
——那是 cargo 的码，不是 `tee` 的码；不关 `-e` 的话管道一失败就在 tee 之后退出，后面三行
永远跑不到。
- Windows 走 pwsh：`PIPESTATUS` 是 bash 语法，改用 `$LASTEXITCODE`（`Tee-Object` 是 cmdlet，
不会改它）。注解的正则不锚 `error:` 那一支，因为 pwsh 把原生 stderr 折成 ErrorRecord 后
行首可能多一截前缀，锚死会漏行。
两条都以 `exit <code>` 结尾，退出码不再经过管道传递。
2026-11-06 20:07:00 +08:00
..
2026-11-06 20:07:00 +08:00
2026-11-05 18:15:37 +08:00
2026-11-05 18:15:37 +08:00
2026-11-06 19:29:47 +08:00
2026-11-06 19:30:10 +08:00
2026-11-06 19:29:47 +08:00