update_manifest.py 脚本逆向拆解：Cangjie Nightly Builds 的版本校验、SHA256 计算与回写自校验

update_manifest.py 脚本逆向拆解Cangjie Nightly Builds 的版本校验、SHA256 计算与回写自校验【免费下载链接】nightly_buildCangjie Nightly Builds 版本归档Nightly版本暂存时间为30天项目地址: https://gitcode.com/Cangjie/nightly_buildCangjie Nightly Builds 是仓颉语言每日构建版本的归档仓库Nightly 版本仅暂存 30 天而 tools/update_manifest.py 是这条发布流水线上的关键脚本——每次 nightly 构建发布后它负责校验版本串、计算或接收SHA256 摘要并把 version / url / hash 三个字段回写到 Scoop 清单文件 bucket/cangjie-nightly.json最后再做一次自校验确保 Windows 用户scoop install时拿到的下载地址与哈希值绝对可靠。本文带你完整拆解这个脚本的四步工作流。这个脚本在整个项目中扮演什么角色仓库结构非常精简核心就三个部分 bucket/cangjie-nightly.jsonScoop bucket 清单告诉 Scoop 去哪里下载、下载后如何校验和部署 tools/update_manifest.py流水线专用脚本负责维护上面这份清单 docs/scoop-install.md面向用户的 Scoop 安装指南Windows。每日流程是构建机产出 SDK zip → 发布为 release → 流水线调用update_manifest.py→ 清单更新 → 用户侧scoop update即可升级。脚本头部注释明确了它的四项职责与退出码约定0 成功 / 1 校验失败 / 2 用法错误见 tools/update_manifest.py#L11-L21。注意它只改 manifest 文件git add/commit/push由调用方完成职责边界非常干净。第一步版本串格式校验与文件名一致性检查这是脚本的第一道防线。脚本用正则约束 nightly 版本串必须是X.Y.Z-pre.数字形态例如1.3.0-alpha.20260902010013两个正则定义在 tools/update_manifest.py#L36-L37版本正则^[0-9.]-[A-Za-z]\.[0-9]$SHA256 正则^[0-9a-fA-F]{64}$更关键的是tag 与文件名必须同串的一致性校验脚本根据版本串拼出期望的文件名cangjie-sdk-windows-x64-版本.zip与实际 zip 文件名比对不一致立即报错退出见 tools/update_manifest.py#L90-L94。 为什么要这么严格注释里提到2025-12 曾出现过 release tag 与产物文件名不一致的事故导致用户按版本号安装直接 404。这道校验就是从事故中沉淀下来的防复发机制。版本串写错任何一位都会 404所以逐字符精确是 nightly 版本管理的铁律。第二步SHA256 摘要如何确定SHA256 是 Scoop 下载后的完整性校验值来源有两条路径tools/update_manifest.py#L96-L104--hash直传如果流水线在构建阶段已经算好哈希直接传参即可脚本只做 64 位十六进制格式校验并统一转小写省掉一次重复计算本地分块计算未传--hash时脚本调用local_sha256函数自行计算核心实现在 tools/update_manifest.py#L45-L51。本地计算采用的是分块读取策略每次从 zip 文件读 1MB1 20字节再喂给 hashlib 累加。nightly 的 SDK 压缩包含 252MB 级别如果一次性read()进内存会直接撑爆构建机内存分块方案则让内存占用恒定在 1MB 左右是处理大文件哈希的标准写法对新手也是很好的范例。第三步回写 manifest 的三个字段校验全部通过后脚本进入回写环节tools/update_manifest.py#L108-L116只精确改动三个位置字段新值来源version命令行传入的版本串architecture.64bit.url下载基址 版本 tag 期望文件名拼接而成的 release 下载地址architecture.64bit.hash第二步确定的 SHA256写文件时有两个容易被忽视的细节以 UTF-8无 BOM编码、newline\n强制换行符、indent4保持 4 空格缩进——这与清单现有的格式风格完全一致避免产生无意义的 diff 噪音。对照 bucket/cangjie-nightly.json 可以看到version、url、hash三处正是每天被脚本刷新的字段其余如bin二进制列表、env_add_path环境变量、checkver版本探测等配置则保持不动。第四步写回后自校验双保险收尾写完不能就算完。脚本会重新读取刚写好的文件解析 JSON 并逐一核对tools/update_manifest.py#L118-L126version是否与传入值一致hash是否一致url是否以期望的产物文件名结尾。任何一项不符就die(self-check failed: ...)退出。这一步防的是磁盘写入异常、JSON 序列化意外等写的时候觉得成功、读的时候面目全非的隐蔽故障——对自动化流水线来说宁可当场失败也不能把一份坏清单推给用户。最后脚本打印更新后的三字段与哈希来源方便在流水线日志中留痕。实际调用方式流水线里长什么样脚本只依赖 Python3 标准库argparse / hashlib / json / re构建机无需安装任何第三方包。标准调用形如摘自脚本头部用法说明python3 tools/update_manifest.py \ --version 1.3.0-alpha.20260902010013 \ --sdk-zip /path/to/cangjie-sdk-windows-x64-1.3.0-alpha.20260902010013.zip \ [--hash sha256] \ [--repo-root /path/to/nightly_build]参数要点--version、--sdk-zip必填--hash可选流水线已算好时传入可免去本地计算--repo-root默认为脚本所在目录的上一级即仓库根一般无需显式指定若 manifest 或 zip 文件不存在、文件名与版本串不符脚本会输出ERROR:前缀信息到 stderr 并以退出码 1 终止流水线据此判定发布失败。对普通用户来说这些细节的好处体现在安装体验上按 docs/scoop-install.md 添加 bucket 后一条命令即可用上当天构建scoop install cangjie-nightly scoop update cangjie-nightly而近 30 天内的任意历史版本也可以用scoop install cangjie-nightly完整版本号精确安装、多版本共存——这背后正是脚本每天维护好的versionurlhash在起作用。小结update_manifest.py不到 140 行却把自动化发布中最容易出事故的环节全部覆盖 版本串与文件名一致性校验防错版、 分块 SHA256 计算兼顾大文件内存安全、✍️ 保持格式风格的最小化回写、️ 写后自校验兜底。对于想理解Nightly Builds 版本归档这类仓库如何保证每日构建可靠可装的读者这个脚本是一个麻雀虽小、五脏俱全的参考样本。【免费下载链接】nightly_buildCangjie Nightly Builds 版本归档Nightly版本暂存时间为30天项目地址: https://gitcode.com/Cangjie/nightly_build创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考