|
|
ed8f28ea6c
|
test(kernelboot,ci): 用真实启动图装配整机补判据，race 门由写死两包扩到全仓
背景：老大指出「CI 测试不够灵活、覆盖不到内核方方面面，应从启动图入手」。
先定位 CI 失败：六个门禁在基线上本地全绿，复现不出红 —— 实质是**覆盖面太窄**
而非配置写错（原 race 门只跑 ./internal/agent/core/ 与 ./cmd/waiter/ 两个包，
kernelboot 下 scheduler/syncbus/stress 的并发用例全在裸奔，绿是因为没测到）。
## 一、新增 internal/kernelboot/modules/registry_test.go（913 行，5 条判据）
kernelboot 自身判据很密（图编解码/分层/调度/迁移回滚/并发压测），但**全部用
假模块**在图上验算法。「真实 17 个模块按真实登记表装配成整机、逐层启动、
再严格逆序关闭」一条用例都没有。这中间藏着一整类失败：算法对、单模块对，
但装配起来不对（漏挂模块 / 某层关闭函数没登记 / 关闭顺序反了）。
5 条判据（零假模块，全部基于 kernelmod.Registered() 的 17 个真模块）：
- TestRealRegistryAssemblesWholeMachine：每模块进图、设施真就绪（不是"登记过"）
- TestLayerTopologyIsRespected：层间严格有序、层内两两无依赖、分层真带来并行
- TestShutdownIsStrictlyReverseLayerOrder：关闭严格逆序（实测哨兵序 [4 3 2 1 0]）
- TestShutdownLeavesNoResidue：连续启停 3 轮，goroutine 回基线 + 临时目录删净
+ syncbus 订阅者不增长
- TestEveryRegisteredModuleIsCompiledIn：源码树扫描与登记表**双向**集合比对
### 判据 5 的真相源为何是"类型+四方法集"而不是 Register 调用点（初版栽过）
初版扫 `kernelmod.Register(...)` 调用点。实测：删掉叶子模块 multimodal 的
init() 后，**5 条判据全绿** —— 调用点消失 ⇒ 源码侧与登记表侧同时少一个 ⇒
集合比对照样相等。而"忘记初始化注册"恰是它声称要抓的场景。
根因是把「要检测的对象」当成了「检测的入口」，入口一被破坏就失去视野。
改成扫「实现了 Name/Requires/Provides/Init 四方法的类型」：模块哪怕不
Register、不被 import，四个方法仍写在源码里。
坑：本仓大量类型都叫 Module，只按类型名做键会撞成一堆（实测撞到只剩 2 个）
⇒ 用「目录+类型名」复合键；agent 是指针接收者 *Module，要处理 StarExpr。
修后恰扫出 17 个类型，与登记表 17 个名字一一对应，零误报。
### 失败面逐条实测（不是注释声称）
M1 删叶子模块 init() → 只有判据 5 红（1–4 全绿，这正是它存在的理由）
M2 CloseAll 逆序改正序 → 判据 3 红
M3 删聚合 import → 判据 5 红
其余：跳过某层会让内核 panic（llm 拿到 nil LuaVM，SIGSEGV）；层顺序改逆序
红在装配失败（依赖数据为 nil）而非顺序断言 —— 这两种能发现但报错可读性差，
已写入文件注释，修它属业务改动（另派）。
## 二、.github/workflows/ci.yml
- race 门：写死两包 → `go list ./...` 全仓动态枚举（剔除 cmd/gui，
枚举 <50 包则响亮失败），实测 92 包
- 新增 -skip 排除表：每项必须写「原因 + 修复单号」，无原因该步骤自身失败；
每次 CI 打印完整清单，避免"排除项静默腐烂"
- 新增「已知红的可核对证据」步：用**静态断言**检查两处已知缺陷是否仍在
（webui gzipResponseWriter 无锁、kernel Set* 无锁直写）。
不用"DATA RACE 报告数>0"当断言 —— 实测这些竞争偶发（正向 0 条、
另一次 8 条），那样必然假绿。
- cross 门：cmd 清单由写死 → 逐包 `CGO_ENABLED=0 go build` 实测枚举
（实测 4 个纯 Go / 8 个依赖 cgo；homed-key-rotate 一直是纯 Go 却从没进过
清单，白少一个覆盖）；矩阵补 windows/arm64 与 linux/386
- go job：单列「整机启动图判据」一步（带 -count=1，便于失败定位）
## 三、新增 .github/scripts/check-ci-gates.py（180 行）
官方复核时发现：第一版判据只跑 gofmt/build/vet/go test，**完全不校验 ci.yml**，
而 ci.yml 正是改动占比最大的部分 —— 用「删掉 cmd/gui 剔除」这个变异咬出了该缺口。
本脚本用 YAML 解析断言 6 类门禁机制仍在，并给每个 run 步骤做 bash -n。
关键细节：`run: |` 块里的 `# ...` 是**字符串不是 YAML 注释**，`"cmd/gui" in run`
会被一句说明性注释满足 —— 真把 grep -v 删掉断言仍绿。故剥 shell 注释后再断言，
并给剥注释函数**本身**加了自测。
## 四、两处纯注释纠偏
- modules/registry.go：文档写「防漏 import 判据见 registry_test.go」（main 上该
文件当时不存在）、第④步指向 `modules/imports.go`（真实位置是
internal/kernelmod/all/all.go）。已纠正并落地为两条判据的指引。
- kernelboot/kernelstate.go：把「判据见 modules」具体化为函数名。
## 门禁（全部 -count=1，无缓存）
go build ./... = 0
go vet ./... = 0
go test ./... = 0（59 ok / 0 FAIL）
go test -race 91 包 = 0（58 ok / 0 FAIL）
check-ci-gates.py = 0
证据步骤正向 = 0；反向（给 SetLuaVM 加锁）= 1（证明是活断言不是死代码）
## 已知红（均待另开线，本线不越界改业务）
1. 内核：agent.wirePluginSDK 与 pluginhost.injectBaseDeps 在第 4 层并行重复
写同一批 plugin.Registry 字段，而 Set* 全不取锁（r.mu 存在但没用）。
实测偶发约 4%（1/25）。当前以 pkg 级排除临时挡住，**定性为临时手段**；
唯一出口是给 Set* 加锁（修复单 KERNEL-REGISTRY-SETLOCK）。
2. webui：gzipResponseWriter 的 mode/wroteHeader/buf 无锁，handler goroutine
与增量写 goroutine 并发写同一 ResponseWriter（修复单 WEBUI-GZIP-RACE）。
3. internal/agent/core TestStress_Nesting... 时序偶发（-race 放大 300ms 假设，
无 DATA RACE 报告），未 skip，复现命令记在 ci.yml 注释里。
边界：未改任何内核业务逻辑（两个业务文件 diff 逐行只有注释）；未 push、未开 PR。
|
2026-10-24 11:30:51 +08:00 |
|
|
|
777f2f810d
|
fix(ci): gitcode 目标仓前置检查加有界重试（网络抖动不再误判）
2026-10-21 的 main 流水线（dfc4e16）里，「前置检查 gitcode 目标仓是否存在」
首次执行时 gitcode 没有给出预期响应，一次 ls-remote 判失败 ⇒ sync job 红；
重跑立刻全绿。把一次网络抖动翻译成「镜像同步坏了」，是纯噪声。
改法：只对**网络层**失败重试，其余立即失败。
- 网络层（DNS/连接重置/TLS/超时/EOF）→ 最多 3 次，退避 5s、10s
- 仓不存在（gitcode 实测：could not be found + **403**，不是 404）
→ 立即失败，不重试。重试只会把「去建仓」拖成十几秒空等
- 凭据问题（401/403 但不带 not-found 特征）→ 立即失败，不重试
（token 错了等 15 秒也不会变对）
- 分类顺序上 notfound 必须先于 403：gitcode 的「仓不存在」响应里
**同时**含 could not be found 与 error: 403，先判 403 会把真问题贴上
「凭据问题」的错误标签
- 每次尝试打一行「第 N/M 次探测失败（类别）：摘要」；重试提示打到 stderr
（⏳ … 秒后重试），Actions 日志里一眼看得出发生过重试
- 耗尽重试时整段回放每次尝试的摘要，并明确写「判定：网络问题」
—— 与「仓不存在」/「凭据问题」的判定措辞互不相同，可直接 grep 区分
同口径：**抽成 .github/scripts/check-gitcode-repo.sh，两个 workflow 共用同一个
文件**，而不是两边各写一份「逐字一致」的脚本 —— 后者迟早会漂。ci.yml 的
sync-gitcode-main 与 release.yml 的 sync-gitcode 各留 1 行 bash 调用。
（抽得出公共片段，故没有采用「两边逐字改」的方案。）
token 安全：GC_URL 含 token，永不 echo；所有输出先过 redact()。脱敏两道：
先按字面量遮 token（BRE 元字符先转义），再按 URL 结构遮 userinfo@。
结构式的 password 段**不能排除 `/`** —— 真实 token 可以含 `/`，第一版写成
[^@/[:space:]]* 时 `https://user:tok/en@host` 匹配不上，只剩字面量一道兜住
（判据 C6 首次就是红的）。
判据与变异（9 组正向 / 8 条变异，全部咬住）：
判据脚本与变异脚本见 commondev 台账 criteria/b7-gitcode-precheck-retry{,.mutations}.sh。
正向覆盖：重试次数上限（恰好 3 次探测）、仓不存在时 1 次即失败无重试痕迹、
首次成功无重试噪声、抖动后第 2 次成功、凭据问题不重试、token 不进日志、
默认退避真的是 5s/10s（用假 sleep 记录入参，不真等 15 秒）、
两处 workflow 都调同一脚本事 yaml 可解析 + bash -n。
变异 8/8 咬住：默认次数 3→1、退避→0、仓不存在也重试、去掉上限、
去掉重试提示、清空 notfound 特征串、去掉结构式脱敏、ci.yml 退回内联 ls-remote。
过程中修掉三处自己判据的盲区（都不是改产物去迁就判据，而是补判据）：
1. M2（退避→0/0）首次未被咬住 ⇒ 补 C7「默认退避 = 5 10」（假 sleep 记录入参）
2. M7（删结构式脱敏）首次未被咬住 ⇒ 补 C7b：userinfo 密码用**别的** secret
且**含 `/`**。C6 用当前 token 的字面量做输入，字面量替换本身就能抹掉，
于是结构式规则删了也照样绿；且密码不含 `/` 时兜底的裸 user@ 规则会顶上，
同样验不出来
3. C7b 第一版断言 grep 'JianFeeeee' 会误报 —— 脚本正常输出里就有
gitcode.com/JianFeeeee/HologramAgent（那是路径不是凭据），改为断言
userinfo 形态（://JianFeeeee[:@]）
真实网络实测（不是只跑假 git）：
- 仓存在：目标仓可访问，rc=0
- 仓不存在：1 次探测即失败，日志含 could not be found + 403，rc=1
- 网络失败：3 次探测 + 2 次退避，总耗时 5.7s（退避调成 1s/1s），rc=1
yaml.safe_load 三个 workflow 全部可解析；bash -n 通过。
未改动（留待裁决）：deploy/scripts/upload_assets.py docstring 里
「SDK 仓传 JianFeeeee/homeagent-sdk」指 gitcode 侧、与实测一致
（gitcode: homeagent-sdk=200 / homeagentsdk=404；GitHub 相反），保持原样。
|
2026-10-21 23:46:01 +08:00 |
|
