zijunchiang
20c6682202
「发布包 == 打标签的树」此前只抽查几个文件，必然会漏。新增 build/check-tracked-release.py（纯标准库，直接读 LZMA zip）：对包内**每一个**文件 按路径决定基准 —— OpenDance.exe / OpenDance.pck 比工作树 build/windows/ 的导出结果， 其余文件比 git show <tag>:<路径>；内容不一致 / 包内多余 / 构建产物缺失都会列出并退出 1。 已接入 build/accept-release.sh（第 0 步）与 build/package-release.sh 的提示。 实测（已发布的 v0.2.5 资产重新下载后）： 包内 13 个文件：源码/文档 11（与 tag v0.2.5 比）+ 构建产物 2（与工作树导出比） ✓ 逐文件一致：0 处不一致 / 0 处多余 / 0 处缺失 反向验证：把包内 README.txt 追加一行后用 7z 重打成 LZMA zip → ✗ 内容不一致 1 处（README.txt），退出码 1。 踩坑：脚本第一版把 BUILD_OUTPUTS 的键一律当目录前缀（rel[len(prefix):]）， 而本仓产物是单文件，拼出 build/windows/OpenDance.exe/ 导致误报「工作树缺失」； 现在区分「以 / 结尾的目录前缀」与「精确文件名」两种键。
2.4 KiB
2.4 KiB
T-WIN-025：逐文件核对「发布包 == 打标签的树」
- 状态: done
- 依赖: T-WIN-018（发布包级验收）
- 文档: v1.6 §5.3 / §7.7
- 契约: 不涉及
为什么需要
「发布包里的东西必须等于打标签的那棵树」此前只靠抽查几个文件
（README、contracts/VERSION…），而抽查必然会漏。上一轮实测暴露两个认知错误：
- Web 的发布包包含
web-server/test/**（33 个文件），而我此前以为不含； - 发布包里另有构建产物（本仓是
OpenDance.exe/OpenDance.pck）与 git 无关， 必须与工作树的导出结果比。
实现
build/check-tracked-release.py（纯标准库，.zip 直接读，LZMA 也支持）：
对包内每一个文件按路径决定比较基准
| 路径 | 比较基准 |
|---|---|
OpenDance.exe / OpenDance.pck（BUILD_OUTPUTS） |
工作树 build/windows/ 下的导出产物 |
| 其余全部 | git show <tag>:<路径> |
任一内容不一致 / 包内多余（既不在 git 也不是声明的构建产物）/
构建产物在工作树缺失 都会列出并以非 0 退出。已接入 build/accept-release.sh
（第 0 步；目标须是 .zip 且仓库里有对应 tag）与 build/package-release.sh 的提示。
实测（已发布的 v0.2.5 资产重新下载后跑）
[accept] 逐文件核对：发布包 == tag v0.2.5
包内 13 个文件：源码/文档 11（与 tag 比）、构建产物 2（与工作树构建比）
✓ 逐文件一致：0 处不一致 / 0 处多余 / 0 处缺失
反向验证：把包内 README.txt 追加一行后用 7z 重新打成 LZMA zip →
✗ 内容不一致 1 处：· README.txt（与 v0.2.5 的内容不一致）
✗ 发布包与打标签的树不一致 退出码=1
踩坑
脚本第一版把 BUILD_OUTPUTS 的键一律当目录前缀处理（rel[len(prefix):]），
而本仓与 Android 的产物是单文件（键不带 /），于是拼出
build/windows/OpenDance.exe/ 这种路径，误报「构建产物在工作树缺失」。
现在区分两种键：以 / 结尾的是目录前缀，否则是精确文件名。
与「产物内开发残留检查」的区别
| 检查 | 回答的问题 |
|---|---|
list-pck.gd（T-WIN-023） |
产物内部（pck 里）有没有混进开发/验收工具 |
| 本脚本（T-WIN-025） | 产物对着仓库看有没有多、少、被改过的文件 |