|
|
0fe239f8cd
|
docs(ci): 记录 cmd/gui 假告警的根因与本机补丁（手册 §6）
每轮编辑后 pi-lens 都会报 `FAIL ./cmd/gui [setup failed]`，看着像仓库有测试红了，
实为工具缺陷。本会话内重复触发 20+ 次，每次都需人工复核，故完整记录并修掉。
根因（两个缺陷叠加）：
1. pi-lens 的 runner 按**仓库根**检测（本仓有 go.mod ⇒ go），但被测文件可能
在另一种语言的项目里；`cmd/gui/*.test.mjs` 命中通用测试命名 ⇒ 对纯 Electron
目录生成 `go test -run . ./cmd/gui` ⇒ 必然 "no Go files" 失败。
2. 该失败进入进程内 failedTestsByRunner，而 failed-first 策略此后**每次**编辑
都优先重跑它（与当前编辑的文件无关）；条目只在测试**通过**时移除 ⇒ 永不自愈。
日志形态：turn_end: README.md → test go cmd/gui/sse-backoff.test.mjs (failed-first)
为什么不能靠配置关掉（都实测/读码确认）：
- `.pi-lens.json` 是项目级，只认 ignore/rules/maxProjectFiles/reviewGraph/trivy
+ 三个改动开关；`tests` 是全局级，写进去会被忽略并告警。
- 全局 `{"tests":{"enabled":false}}` 会一起关掉**所有项目**的回合末测试反馈，
为一个仓库的误报付全局代价 —— 不值。
- `ignore` 也挡不住：它只作用于扫描，不参与测试目标选择。
修法：给 pi-lens 的 getTestRunTarget 加一道「该 runner 真能跑这个目标吗」的校验
（go：目标目录至少有一个 .go 文件），不能跑就拒并清掉那条不可运行的失败记录。
runTestFileAsync 只有这一个调用点，是唯一收口。
验证：node --check 过语法；/usr/bin/diff 核对为纯新增零删除；
真实路径模拟 6/6 符合预期（cmd/gui 的 .mjs → 拒；真 Go 测试文件 → 放行）；
go test ./... 仍 43 包全绿。
注意：补丁在 ~/.pi/agent/npm/... 里，pi-lens 升级后会被覆盖（届时误报会回来，
不影响仓库，只是噪音）。备份 index.js.orig-*，回退方式写在本节。
本手册同时补上 §6.1 症状 / §6.2 根因 / §6.3 配置为何无效 / §6.4 修法与回退。
|
2026-09-29 21:24:09 +08:00 |
|
|
|
16b6288ea6
|
docs(ci): 记录 GITCODE_TOKEN 已配置及其验收方式
原 3.6 节只写「未配置时该 job 显式跳过」，读起来像是一直没配。补上实际状态：
两仓 secret 均已配置（值取自 ~/.git-credentials 的 gitcode 条目），
配置命令走 stdin（避免 token 出现在进程列表），以及三道等价验收 ——
因为 sync job 只在**新版本**发版时运行（prepare.outputs.exists == 'false'），
历史 tag 触发不了，无法用旧版本实跑，所以要用等价命令验：
① gh secret list 确认 secret 在
② /api/v5/user 确认 token 有效
③ 带 private-token 头读 release 确认 job 用的鉴权方式可用（两仓都测）
并记下一条待改进项：该 token 是**宽范围个人令牌**（可读 92 仓/48 私有、有写权限），
而 CI 只需这两个仓；更稳的是换一枚仅限这两仓的令牌，把 CI 泄漏的影响面收窄。
当前按用户 2026-09-29 的决定保持原状。
|
2026-09-29 17:42:46 +08:00 |
|
|
|
f339850ffb
|
docs(ci): CI/CD 流水线手册 —— 用法、机制与 6 个踩过的坑
仓库迁 GitHub 后新增两条流水线（ci.yml / release.yml），但用法与机制
此前只存在于 workflow 的注释和提交信息里。发版是高频操作，写成手册。
内容：
- §1 CI 六个 job 与「明确不进 CI」的清单（真机/密钥/内网依赖）
- §2 发版标准流程、幂等闸门（tag 存在即跳过）、
发版门（go build 硬门 + go test 可用 [skip-release-tests] 跳过）
- §2.5 构建资产（ci-assets-v1）的托管与升级方式
- §3 六个实测踩过的坑：
3.1 workflow 文件必须存在于目标分支（否则推 release/** 不触发）
3.2 runner 无 electron 缓存 ⇒ 必须 npm ci（且不能用 --production）
3.3 管道里的 grep -q 因 SIGPIPE 误杀检测（800M 包必炸）
3.4 gh 在非 git 目录要显式 --repo
3.5 gitcode 上传的 ASSET_DIR + 裸名语义
3.6 手工补发 gitcode 附件的流程
- §4 SDK 仓的差异（独立 module 测试要跑两处、CGO 不需要）
- §5 关于失败邮件的说明（可能是验证步骤自身 bug 的假警报）
markdownlint 全绿（两个产物清单代码块补了 text 语言标注）。
|
2026-09-29 15:03:05 +08:00 |
|
