| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
ci(check): 测试门换 nextest,并给 CI 单独一套并发与超时 check.yml 的测试步用的是 cargo test --workspace —— 一个 test binary 跑完才 跑下一个,而这个 workspace 有 91 个 integration test 文件。kernel 那 305 个测试 实测 570s,其中 CPU 只占 1.3s,其余全在空等;nextest 是 0.64s。注释里担心的 「~94 次外部命令 spawn / ~27 次 $HOME 查找 / ~24 次端口绑定」,进程隔离也比 cargo test 的单进程多线程模型更容易跑通。 只换 runner,一道门的松紧都没动: - 唯一的阻塞门仍是 cargo check --workspace --all-targets(注释说的"这一步 单独就能当天抓住 v5.0.9 那个漂移")。 - 测试步仍是 continue-on-error: true。促正条件没满足 —— 注释写的是"等它在 Linux runner 上绿一次",换了 runner 之后更没绿过。PROMOTE 那段原样留着。 - 装 nextest 这步也设成报告态。它是给一个还不算门的步骤做的基础设施,不该让 一次网络抖动把 PR 判红 —— 那正是这仓库反复写的"为错误原因判红的门会被关掉"。 促正时三步一起促。 补一步 cargo test --workspace --doc:nextest 不跑 doctest,而原来那句 cargo test --workspace 是带着 doctest 的,不补就是静默丢覆盖。 .config/nextest.toml 的 ci profile 加两条,都是冲着"首跑别为错误原因判红"去的: - test-threads = "num-cpus" —— 不继承 default 的 6,那是按某台 8 核开发机调 的,runner 核数不同会过度订阅。 - slow-timeout 从 30s/120s 放宽到 60s/240s —— runner 比开发机慢,首跑因超时 判红最可能的结果是有人把门关掉,而不是去修测试。 已验证:ci profile 能被 nextest 正确加载(with nextest profile: ci,305 passed); linux 安装 URL 返回 11.8MB tar,内含 ELF 64-bit x86-64 可执行文件;YAML 可解析, 阻塞/报告态画像逐步复核过。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PTxnhY4vdhmeJ76fzsCHAZ | 1 个月前 |