NeuralScreen发布工程拆解:字节级可复现构建、runtime-manifest与200+回归测试 【免费下载链接】NeuralScreenDLSS 5 NR on your whole Windows desktop, in real time with Boost, FG, etc. RTX 30/40/50, 12 languages, user presets, recording with audio, one-window mode.项目地址https://gitcode.com/gh_mirrors/dl/NeuralScreen点击查看免费下载NeuralScreen 是一款把 NVIDIA DLSS 5 神经渲染实时应用到整个 Windows 桌面的开源工具支持 RTX 30/40/50、Boost、帧生成FG、带音频的录屏与 12 种语言界面。本文拆解它发布工程中最值得学习的部分字节级可复现构建、用 runtime-manifest.json 给每个字节钉指纹的清单机制以及 200 个回归测试组成的发布门禁。 一次发布到底交付什么8 个资产多一个都不行完整流程写在 RELEASING.md 里。一次发布正好是8 个资产#资产由谁产生1neuralscreen-vX.Y.Z-full.zipbuild_release_zip.py2SHA256SUMSbuilder 附带的校验和文件3runtime-manifest.json仓库跟踪文件builder 校验并固定4THIRD-PARTY-NOTICES.md仓库跟踪文件5–8README.md/README.ru.md/TECHNICAL.md/TECHNICAL.ru.md手动单独上传校验器 verify_github.py 持有这 8 项的白名单缺一个报 missing多一个报 extra。文档里特意解释了多一个检查的由来——曾经有文档图片被误传成发布资产而该有的都在这一检查完全没发现。这种从事故中补漏洞的思路贯穿了整个发布体系。 字节级可复现构建同一个 commit 永远构建出同一个 ZIP构建器 build_release_zip.py 顶部就固定了版本号常量当前为VERSION 2.4.0并刻意做了几件反直觉的事来保证确定性ZIP 时间戳钉死build_release_zip.py 中ZIP_TIMESTAMP (1980, 1, 1, 0, 0, 0)、ZIP_MODE 0o100644 16——所有条目的时间戳统一为 1980-01-01权限统一 0644不写入时钟包内的VERSION.txt只含版本、tag、commit 与 manifest 摘要没有构建于某时某刻这类随时间变化的行规范化 JSONruntime-manifest.json必须满足indent2, ensure_asciiFalse, sort_keysTrue加末尾换行任何其它排版都会以runtime-manifest.json is not canonical UTF-8 JSON失败。结果就是同一 commit 构建两次得到的 ZIP 逐字节相同。校验器还会复查成员顺序、时间戳与模式ZIP member order is not canonical、ZIP member timestamp is not deterministic。 runtime-manifest.json给 1333 个文件逐一钉上指纹打开 runtime-manifest.json 可以看到当前固定的是v2.4.0包内共1333 个文件。清单由四层组成version_sources三处版本来源文件及其提取出的值防止版本漂移runtime.*随包发布的全部runtime/文件——数量、整树摘要tree digest、每个文件的 size 与 sha256外加 9 个必需运行时产物NeuralScreen.exe、native/nvngx*.dll、Spout*.dll、runtime/python.exe等单独固定package.*完整载荷清单每条记录标注origin: git附 Git blob OID或origin: generatedsize/sha256 取 ZIP 内实际字节。NeuralScreen.bat这类eolcrlf文件还有专门记录CRLF 字节与 LF blob 的差异被显式声明source_inventory全部跟踪的 native 源码、shader 与资源及其 Git blob OID。清单重新固定re-pin由 builder 的--write-runtime-manifest完成前提是跟踪的工作树干净assert_clean_tracked_tree。这意味着re-pin 之后任何一次新的 commit 都会让清单过期builder 会直接拒绝构建。清单不是一份参考文档而是一道硬门禁。️ 三道独立防线builder、本地门禁、离线验证器同一个约定被三处独立检查任何一处漏网都有后手防线文件职责构建时build_release_zip.py拒绝脏树、未打 tag 的 HEAD、版本漂移、架构缺失runtime architecture mismatch: missing sm_75, sm_89全部以RELEASE CONTRACT FAILED 退出码 2 收场本地门禁tests/autocheck.py静态检查worker 二进制比源码新、ZIP 完整性、发布说明长度5000 字符等发布后verify_github.py离线复核文档与 tag 的 Git blob 逐字节比对、8 个资产齐全、上传的 tracked 资产与 tag 完全一致、发布是 Latest、仓库描述仍含user presets与12 languages版本号的一致性检查是这套防线的样板builder 的assert_version_coherence、验证器的version source differs from manifest、以及 tests/test_release_contract.py 三方独立比对。 200 回归测试每个测试必须恰好归一组测试入口是 tests/run_tests.py一条命令跑完静态检查、全部回归测试和冒烟测试runtime\python.exe tests\run_tests.py # 静态 测试 冒烟 runtime\python.exe tests\run_tests.py --gui # 外加完整 GUI 周期 runtime\python.exe tests\run_tests.py --only out_shm # 按名只跑一个这个 runner 的存在本身源于一次事故审计 #3 改坏了共享内存像素通道test_out_shm.py能抓住它但没有人手动跑过它——回归就这么溜进了发布。于是有了一条命令、一个裁决、任何失败都返回非零退出码。几个值得借鉴的设计见 tests/run_tests.py四组执行分级unit/static→WARP→GPU→GUI-E2E组顺序即执行顺序每个跟踪的测试必须恰好属于一组新增测试文件没登记组整个运行直接RESULT: ERROR - unrouted test: name同属两组同样报错——这是 fail-closed而不是默认归入某个杂项组每个测试带一句ABOUT说明失败时名字本身就告诉你坏的是什么不用翻文件settle()等待机制上一个测试的 worker 进程没死干净就不启动下一个避免测的是进程回收而不是被测代码结果状态严格分为PASS / FAIL / SKIP / ERROR / TIMEOUT只有规范的 SKIP 行才能把测试降级为跳过。GUI-E2E 组会真的接管屏幕拉起界面与录屏所以发布前跑--gui时要离开机器且确保没有 NeuralScreen 实例在运行。 版本号写在 4 个地方的 6 行里版本漂移是发布事故的重灾区。RELEASING.md 第一节明确列出版本号共出现在3 个文件、6 行字面量中文件形式以 1.15.2 为例build_release_zip.py第 35 行VERSION 1.15.2app/settings_io.py第 192 行APP_VERSION 1.15.2native/launcher.rcFILEVERSION 1,15,2,0、PRODUCTVERSION 1,15,2,0、字符串FileVersion 1.15.2.0、字符串ProductVersion 1.15.2其中launcher.rc的四种形式必须各出现恰好一次注释掉的旧FILEVERSION也算违规must declare exactly one FILEVERSION; found 2。而VERSION常量是唯一的真源tag 只需与它一致——v1.15.2配上VERSION 1.15.1会得到expected tag must be v1.15.1, got v1.15.2。⚠️ 常见错误速查每种操作都有对应的失败信息RELEASING.md 第 5 节把常见错误与报错一一对照摘录几条你做了什么看到什么re-pin 后又提交了新 commitruntime-manifest.json does not match tagged runtime/source inventory忘了提交 re-pin 后的清单tracked working tree is dirty; commit or restore these paths:tag 后又 committag vX.Y.Z resolves to a, HEAD is b只改了.rc没重编 launcherNeuralScreen.exe version resource differs from the release; ... - rerun native\build-launcher.batDLL 少了某个架构runtime architecture mismatch: missing sm_86发布说明超 5000 字符the release body is 5180 characters - too long且只在发布后才发现注意最后一条的教训说明长度检查读的是Latest发布所以它管不住草稿——文档在第 6 节里诚实记录了哪些约定没有机器强制这种如实标注约束边界的做法本身也值得学习。 给贡献者的 10 步发布清单浓缩 RELEASING.md 的操作顺序每步都说明了为什么在这个位置改 6 行版本号builder、settings_io.py、launcher.rc各字段重建 native 二进制native\build-host.bat与native\build-launcher.batworker 必须比源码新launcher 必须带上新版本资源重新生成文档截图_render_docs.py读取main.APP_VERSION必须先于 re-pin 运行提交 1–3 步后 re-pin 清单build_release_zip.py vX.Y.Z --write-runtime-manifest再提交清单跑全套测试runtime\python.exe tests\run_tests.py --gui等RESULT: PASS确认git status --short为空打 tag 并推送tag 最后打且必须恰好解析到 HEAD构建发布包build_release_zip.py vX.Y.Z此时才轮到它出场创建发布8 个资产一次传齐并设为 Latest离线验证verify_github.py vX.Y.Z看到OK: vX.Y.Z on GitHub matches tag, manifest and checksums收工。小结NeuralScreen 的发布体系有三个可迁移的核心思想构建确定性钉死时间戳、规范化输出让同一个 commit 出同一个字节流成为可验证的性质、清单即契约runtime-manifest.json把包里有什么从口头承诺变成逐字节的 sha256 Git blob 证据、检查冗余builder、本地门禁、发布后验证器三方独立比对同一约定任何单一疏漏都有后手兜底。对于任何希望做到可复现、可审计发布的开源项目这套模式都相当有参考价值。参考文件RELEASING.md · build_release_zip.py · verify_github.py · tests/run_tests.py · tests/autocheck.py · TECHNICAL.md赞分享【免费下载链接】NeuralScreenDLSS 5 NR on your whole Windows desktop, in real time with Boost, FG, etc. RTX 30/40/50, 12 languages, user presets, recording with audio, one-window mode.项目地址https://gitcode.com/gh_mirrors/dl/NeuralScreen点击查看免费下载相关推荐Activepieces 架构决策在 Flow Bundle Manifest 中冻结 Piece 版本实现字节级可复现的流程快照Activepieces 架构决策在 Flow Bundle Manifest 中冻结 Piece 版本实现字节级可复现的流程快照 本文解读 Activep工作流自动化后端前端人工智能AI 应用低代码MCP 服务AI Agentvirtualenv 发布验证完全指南PyPI/GitHub 资产核验、SBOM 追溯与字节级可复现构建virtualenv 发布验证完全指南PyPI/GitHub 资产核验、SBOM 追溯与字节级可复现构建 本指南以 virtualenv 官方发布的验证文档为开发工具CLIEasydict 发布构建修复实录asc CLI 参数续行、回归测试与 App Manager 权限配置Easydict 发布构建修复实录 asc CLI 参数续行、回归测试与 App Manager 权限配置 本篇技术指南围绕 Easydict 仓库发布流水线桌面应用AI 应用创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考