优化 AGC 发版脚本的测试：每次改代码都跑，并且不受渠道参数影响 #542

New Issue

2026-09-30T11:51:47+08:00

suzmii commented

2026-09-30 11:51:47 +08:00

一句话

AGC 客户端（桌面 App）的安装包由同一个脚本生成，这个脚本现在有 5 个测试文件保护它，一共 62 个测试，跑完不到 1 秒。问题有两个：这 5 个测试只在 macOS 发版任务里跑，改坏脚本时提交代码不会报错；而且它读环境里的渠道参数，同一个测试在开发渠道能过、在正式渠道必挂。9 月 30 日凌晨的正式发版就是这样被卡住的，官网 macOS 版号停在 0.1.139。这个 Issue 要把这两件事一起改掉。

先把名词说清

发版脚本：apps/ai-game-creator-shell/scripts/build-release.mjs。它按平台和渠道决定安装包叫什么名字、更新地址写在哪里、清单里写什么版本。macOS 和 Windows 的安装包都由它产出。
渠道：安装包属于哪条发布线。dev 是开发版，release 是正式版。
渠道参数：环境变量 AGC_UPDATE_CHANNEL。发版任务启动构建时把它传进去，脚本据此知道这次发哪个渠道。
这 5 个测试：apps/ai-game-creator-shell/scripts/ 下的 build-release.test.mjs、cargo-features.test.mjs、prepare-macos-codex.test.mjs、verify-updater-signature.test.mjs、macos-release-identity.test.mjs。它们校验发版脚本的行为，例如：给 Windows 目标生成的配置里该不该带 NSIS 安装钩子、macOS 首次安装包该选哪个文件、清单里该出现哪些平台。

问题一：几乎没有人在跑这 5 个测试

只有 Jenkins 的 macOS 发版任务会跑它们，位置在真正编译安装包之前，开发渠道和正式渠道都会跑。
Jenkins 的 Windows 发版任务只跑另一个文件 nsis-toolset.test.mjs，不跑这 5 个。
每次提交代码时跑的仓库 CI 不跑它们，本地 npm run check 也不跑。
所以改坏发版脚本时，提交代码不会有任何检查报错，要等 macOS 那台机器跑发版任务才发现。
那台机器是一台办公 Mac，会关机，也会被带走。9 月 24 日晚上到 9 月 29 日中午它离线 5 天，这 5 天里这 5 个测试一次都没跑。

问题二：测试读环境变量，结果随渠道变

测试要判断"这次是哪个渠道"，办法是去读 AGC_UPDATE_CHANNEL，没有把渠道写死在自己的代码里。

9 月 29 日有人加了一条新测试，断言"Windows 安装包里带有旧名字迁移钩子"。这个钩子只有开发渠道需要，因为开发版的显示名改过两次，正式版没改过。但这条测试没有写死渠道，于是：

开发渠道跑到它：渠道是 dev，符合断言，通过。
正式渠道跑到它：渠道是 release，配置里没有这个钩子，测试直接报错 Cannot read properties of undefined (reading 'nsis')。

9 月 30 日凌晨 4 点的正式发版就死在这里：4:00 拉代码，4:01 装依赖，4:02 跑到这批测试就报错退出。没有编译任何东西，官网 macOS 版号因此没有更新。当时同一批测试里另外 4 个文件都是通过的，所以表面上像"代码坏了"，实际是测试的假设和运行环境对不上。

要改成什么样

每次提交代码时都跑这 5 个测试（现在只有 macOS 发版任务跑）。
测试自己写明要用哪个渠道、哪个目标平台，不读外面塞进来的值。同一个测试在 dev 和 release 下结论一致。
仓库 CI 里加一条检查，防止以后又写出"不写明参数、靠外部环境值"的测试。
Windows 相关的用例失败时，不要挡住 macOS 发版。如果确实要互相挡住，就在文档里写明理由。

怎么算改完

在仓库 CI 里能看到这 5 个测试的执行记录，dev 和 release 各跑一次，都通过。
关掉那台 macOS 机器，提交一次改动，仓库 CI 仍然会跑这 5 个测试。
故意写一条读 AGC_UPDATE_CHANNEL 的测试，新加的检查要能让 CI 报错。
docs/【开发运维】本地开发验证与生产运维-2026-05-15.md 里写明这 5 个测试在哪里跑、要传什么参数、归哪个平台管。

这次先不改

发版脚本本身的行为不改。只有开发渠道需要旧名字迁移钩子，正式渠道不需要。
macOS 那台机器老是离线或者被带走的问题，另开一单。

相关

9 月 30 日的事故记录：#536（已关闭，理由见该 Issue 评论）
当时的临时修法：#537（已关闭），以及 master 上的提交 39823b05c
团队记忆：docs/project-memory/shared-memory/pitfalls.md
另外两个 PR（#520、#524）也在改同一批文件，动手前先和它们对一下顺序

## 一句话 AGC 客户端（桌面 App）的安装包由同一个脚本生成，这个脚本现在有 5 个测试文件保护它，一共 62 个测试，跑完不到 1 秒。问题有两个：这 5 个测试只在 macOS 发版任务里跑，改坏脚本时提交代码不会报错；而且它读环境里的渠道参数，同一个测试在开发渠道能过、在正式渠道必挂。9 月 30 日凌晨的正式发版就是这样被卡住的，官网 macOS 版号停在 0.1.139。这个 Issue 要把这两件事一起改掉。 ## 先把名词说清 - **发版脚本**：`apps/ai-game-creator-shell/scripts/build-release.mjs`。它按平台和渠道决定安装包叫什么名字、更新地址写在哪里、清单里写什么版本。macOS 和 Windows 的安装包都由它产出。 - **渠道**：安装包属于哪条发布线。`dev` 是开发版，`release` 是正式版。 - **渠道参数**：环境变量 `AGC_UPDATE_CHANNEL`。发版任务启动构建时把它传进去，脚本据此知道这次发哪个渠道。 - **这 5 个测试**：`apps/ai-game-creator-shell/scripts/` 下的 `build-release.test.mjs`、`cargo-features.test.mjs`、`prepare-macos-codex.test.mjs`、`verify-updater-signature.test.mjs`、`macos-release-identity.test.mjs`。它们校验发版脚本的行为，例如：给 Windows 目标生成的配置里该不该带 NSIS 安装钩子、macOS 首次安装包该选哪个文件、清单里该出现哪些平台。 ## 问题一：几乎没有人在跑这 5 个测试 - 只有 Jenkins 的 macOS 发版任务会跑它们，位置在真正编译安装包之前，开发渠道和正式渠道都会跑。 - Jenkins 的 Windows 发版任务只跑另一个文件 `nsis-toolset.test.mjs`，不跑这 5 个。 - 每次提交代码时跑的仓库 CI 不跑它们，本地 `npm run check` 也不跑。 - 所以改坏发版脚本时，提交代码不会有任何检查报错，要等 macOS 那台机器跑发版任务才发现。 - 那台机器是一台办公 Mac，会关机，也会被带走。9 月 24 日晚上到 9 月 29 日中午它离线 5 天，这 5 天里这 5 个测试一次都没跑。 ## 问题二：测试读环境变量，结果随渠道变测试要判断"这次是哪个渠道"，办法是去读 `AGC_UPDATE_CHANNEL`，没有把渠道写死在自己的代码里。 9 月 29 日有人加了一条新测试，断言"Windows 安装包里带有旧名字迁移钩子"。这个钩子只有开发渠道需要，因为开发版的显示名改过两次，正式版没改过。但这条测试没有写死渠道，于是： - 开发渠道跑到它：渠道是 dev，符合断言，通过。 - 正式渠道跑到它：渠道是 release，配置里没有这个钩子，测试直接报错 `Cannot read properties of undefined (reading 'nsis')`。 9 月 30 日凌晨 4 点的正式发版就死在这里：4:00 拉代码，4:01 装依赖，4:02 跑到这批测试就报错退出。没有编译任何东西，官网 macOS 版号因此没有更新。当时同一批测试里另外 4 个文件都是通过的，所以表面上像"代码坏了"，实际是测试的假设和运行环境对不上。 ## 要改成什么样 1. 每次提交代码时都跑这 5 个测试（现在只有 macOS 发版任务跑）。 2. 测试自己写明要用哪个渠道、哪个目标平台，不读外面塞进来的值。同一个测试在 dev 和 release 下结论一致。 3. 仓库 CI 里加一条检查，防止以后又写出"不写明参数、靠外部环境值"的测试。 4. Windows 相关的用例失败时，不要挡住 macOS 发版。如果确实要互相挡住，就在文档里写明理由。 ## 怎么算改完 1. 在仓库 CI 里能看到这 5 个测试的执行记录，dev 和 release 各跑一次，都通过。 2. 关掉那台 macOS 机器，提交一次改动，仓库 CI 仍然会跑这 5 个测试。 3. 故意写一条读 `AGC_UPDATE_CHANNEL` 的测试，新加的检查要能让 CI 报错。 4. `docs/【开发运维】本地开发验证与生产运维-2026-05-15.md` 里写明这 5 个测试在哪里跑、要传什么参数、归哪个平台管。 ## 这次先不改 - 发版脚本本身的行为不改。只有开发渠道需要旧名字迁移钩子，正式渠道不需要。 - macOS 那台机器老是离线或者被带走的问题，另开一单。 ## 相关 - 9 月 30 日的事故记录：#536（已关闭，理由见该 Issue 评论） - 当时的临时修法：#537（已关闭），以及 master 上的提交 `39823b05c` - 团队记忆：`docs/project-memory/shared-memory/pitfalls.md` - 另外两个 PR（#520、#524）也在改同一批文件，动手前先和它们对一下顺序

suzmii added the

Priority

High

2

Kind/Testing labels 2026-09-30 11:51:47 +08:00

suzmii changed title from ~~AGC 发版脚本契约门禁的设计问题：唯一执行点在 mac 线且输入被渠道参数污染~~ to 改发版脚本时没有 PR 检查会红：这五个回归测试只被接进了 mac 管线（要从设计上修）

2026-09-30 12:00:38 +08:00

suzmii changed title from ~~改发版脚本时没有 PR 检查会红：这五个回归测试只被接进了 mac 管线（要从设计上修）~~ to 优化发版脚本回归测试接入：每 PR 必跑 + 输入确定 + 防复发守卫

2026-09-30 12:06:23 +08:00

suzmii referenced this issue

2026-09-30 12:17:17 +08:00

修复 AGC release 渠道 macOS 发布门禁被环境渠道带挂 #537