ci(release): M140 windows-arm64 改用原生 windows-11-arm runner
交叉编译路线在 CI 上从未成功过一次：v0.2.1 首次真跑即红在 「Windows ARM64 交叉工具链体检」（windows-latest 上探不到 VC/SDK 的 ARM64 库），故按文档标准 runner 表把 arm64 槽位改成原生 windows-11-arm（公开仓免费，4C/16G），产物回到 target/release。 - 槽位表：windows-arm64 os=windows-11-arm、build_dir=target/release； 无交叉槽位后 target 键与 rustup target add / cargo --target 一并删掉 - 体检步骤重写为「Windows ARM64 工具链体检」：失败时打印实际探测到的 VS 根、VC arm64 lib 目录、SDK 的 um/arm64 目录；SDK 不再只认 tail -n1 挑出的单一版本（全版本里找） - dumpbin 定位链补 Hostarm64/arm64 分支，按 RUNNER_ARCH 选宿主工具族 （x64 上绝不挑 arm64 二进制），vswhere/find/PATH 三级与硬门禁不变 - packaging/README.md §1/§3/§4/§7.5 同步原生化与冒烟真跑的说法
This commit is contained in:
AskaEth committed
1 parent
1a290a15a3
commit
b27e86c65b
2 files changed
+90
-90
No files matched your search
+24
-24
@@ -9,7 +9,7 @@
|
||||
| 槽位 | 本版发布 | 产物文件名 | 形态 | 归档内容 |
|
||||
|------|---------|-----------|------|---------|
|
||||
| `windows-x64` | ✅ 发布 | `unlucky-launcher_<ver>_windows_x64.exe` | **裸 exe**（双击即用） | exe 单文件；三份合规文本作为并列 Release 资产 |
|
||||
| `windows-arm64` | ✅ 发布 | `unlucky-launcher_<ver>_windows_arm64.exe` | **裸 exe**（同 x64 策略） | 同上；在 x64 宿主上交叉编译到 `aarch64-pc-windows-msvc` |
|
||||
| `windows-arm64` | ✅ 发布 | `unlucky-launcher_<ver>_windows_arm64.exe` | **裸 exe**（同 x64 策略） | 同上；CI 在**原生** `windows-11-arm` runner 上构建（M140 起，不再交叉编译） |
|
||||
| `linux-x64` | ❌ 不构建（未验证） | `unlucky-launcher_<ver>_linux_x64.tar.gz` | 单二进制归档 | `unlucky-launcher` + `LICENSE` + `NOTICE` + `README.md` |
|
||||
| `linux-arm64` | ❌ 不构建（未验证） | `unlucky-launcher_<ver>_linux_arm64.tar.gz` | 单二进制归档（原生 ARM64 runner 构建） | 同上 |
|
||||
| `macos-arm64` | ❌ 不构建（未验证） | `unlucky-launcher_<ver>_macos_arm64.tar.gz` | 单二进制归档 | 同上 |
|
||||
@@ -32,9 +32,8 @@
|
||||
- `<ver>` 不带前导 `v`（tag 是 `v0.2.1`，文件名是 `0.2.1`）——由脚本统一裁剪。
|
||||
- UNIX 归档内 `mtime`/`uid`/`gid` 归零、权限固定（二进制 0755、文本 0644），
|
||||
同源构建的 sha256 不受打包时刻影响。
|
||||
- **架构不靠猜**：脚本打包前回读二进制的可执行文件头（PE 机器码 / ELF `e_machine` /
|
||||
Mach-O `cputype`），与槽位声明的架构不符即失败——交叉槽位（x64 宿主产 arm64 exe）不会
|
||||
出现"名字是 arm64、内容还是 x64"的假产物。
|
||||
- **架构不靠猜**：脚本打包前回读二进制的可执行文件头（PE 机器码 / ELF `e_machine` / Mach-O
|
||||
`cputype`），与槽位声明的架构不符即失败——不会出现"名字是 arm64、内容还是 x64"的假产物。
|
||||
|
||||
## 2. 版本来源（唯一真相源）
|
||||
|
||||
@@ -64,7 +63,7 @@ python packaging/make_artifacts.py --no-smoke # 跳过 ull --version 冒
|
||||
macOS x64），其它组合直接报错退出——不在矩阵里的平台不出"凑合能跑"的产物。
|
||||
|
||||
交叉构建（例如在 x64 宿主上产 Windows arm64 产物）靠两个参数把"产物根"和"槽位"显式喂进去，
|
||||
脚本不去猜宿主与产物是不是同一架构：
|
||||
脚本不去猜宿主与产物是不是同一架构（**CI 不用这条路径**，见下）：
|
||||
|
||||
```bash
|
||||
rustup target add aarch64-pc-windows-msvc
|
||||
@@ -75,8 +74,8 @@ python packaging/make_artifacts.py --slot windows-arm64 \
|
||||
```
|
||||
|
||||
`--slot` 与宿主槽位不一致时，`ull --version` 冒烟会**自动跳过并打印原因**（arm64 产物在 x64
|
||||
宿主机上根本执行不了；拿"跳过"当通过是假证据，所以跳过永远带原因）——那条路径的验证只能落在
|
||||
CI 真机上：`windows-arm64` 由 cross 构建产物 + M50 的 dumpbin 导入表门禁覆盖；`linux-arm64` 的同类
|
||||
宿主机上根本执行不了；拿"跳过"当通过是假证据，所以跳过永远带原因）。**CI 不走交叉**（M140）：
|
||||
`windows-arm64` 在原生 `windows-11-arm` 上编，宿主=产物架构 → 冒烟**真跑**；`linux-arm64` 的同类
|
||||
冒烟只在 `all_slots=true` 的取证跑里出现（`ubuntu-22.04-arm` 原生 runner 上真跑 `ull --version`）。
|
||||
|
||||
### CI（默认只跑两个 Windows 槽位；`all_slots=true` 才整表六槽位）
|
||||
@@ -89,15 +88,16 @@ CI 真机上：`windows-arm64` 由 cross 构建产物 + M50 的 dumpbin 导入
|
||||
分支 ref 的 dispatch 与 push 一样被 `release` job 的 `if: github.ref_type == 'tag'` 挡在发布之外，所以
|
||||
「dispatch 只构建不发布」与「dispatch 能关 pre-release」是两条互不冲突的规则。
|
||||
- 矩阵**由 `plan` job 按 `all_slots` 生成**（`matrix: ${{ fromJSON(needs.plan.outputs.matrix) }}`：矩阵本身
|
||||
不能带 `if`，而 `strategy` 可读 `needs`），槽位表只在该 job 里有一份：`windows-latest` x64（MSVC +
|
||||
`-C target-feature=+crt-static`，产物在 `target/release`）与 `windows-latest` **交叉编译**到
|
||||
`aarch64-pc-windows-msvc`（产物在 `target/aarch64-pc-windows-msvc/release`）标 `mode: ci`（默认编）；
|
||||
不能带 `if`，而 `strategy` 可读 `needs`），槽位表只在该 job 里有一份：`windows-latest` x64 与
|
||||
**原生** `windows-11-arm` arm64（M140；后者是公开仓免费的标准 arm64 runner，4C/16G）——两者都是 MSVC +
|
||||
`-C target-feature=+crt-static`、产物都在 `target/release`，标 `mode: ci`（默认编）；
|
||||
`ubuntu-22.04`（glibc 2.35 地板）/ `ubuntu-22.04-arm`（原生 ARM64，同地板）/ `macos-latest` /
|
||||
`macos-15-intel` 标 `mode: probe`——**未验证，默认一个都不编**，只有 `all_slots=true` 才进矩阵。
|
||||
- 每个槽位 `cargo build --release --locked`（交叉槽位多两步：`rustup target add` + ARM64 库体检
|
||||
——查 VC 的 `lib/arm64/libcmt.lib`（`+crt-static` 靠它）与 SDK 的 `um/arm64/kernel32.lib`，
|
||||
缺了直接给出"给 VS 加 `VC.Tools.ARM64` 或改用原生 `windows-11-arm`"的可执行提示）→
|
||||
`make_artifacts.py --slot … --build-dir …` → 归档内容自检 → 上传 artifact。
|
||||
- 每个槽位 `cargo build --release --locked`（**不传 `--target`**：每槽原生编译，交叉槽位与 `rustup
|
||||
target add` 一并没了）。arm64 槽位多一步编译前体检：查 VC 的 `lib/arm64/libcmt.lib`（`+crt-static`
|
||||
靠它）与 SDK 的 `um/arm64/kernel32.lib`，缺了就 fail 并把**实际探测到的目录全打出来**（2026-11-06
|
||||
那次只报"缺失"，看不出是镜像没装还是探测写错）→ `make_artifacts.py --slot … --build-dir …` →
|
||||
归档内容自检 → 上传 artifact。
|
||||
- **发布白名单（`PUBLISH_SLOTS`，唯一开关）**：默认只构建两个 Windows 槽位，只有白名单里的槽位进 Release 与
|
||||
`SHA256SUMS.txt`——当前 = `windows-x64 windows-arm64`；四档未验证的（默认连构建都不跑）不推给用户。
|
||||
将来某槽位真机验证通过：`plan` 槽位表里把它的 `mode` 从 `probe` 改成 `ci`、把键加进这一行（齐全性检查
|
||||
@@ -133,12 +133,12 @@ Windows 为什么用 MSVC 静态 CRT 而不是本机这套 GNU 工具链：两
|
||||
### Windows ARM64（Win11 on ARM）
|
||||
|
||||
产物形态与门禁跟 x64 一模一样（裸 exe + 静态 CRT + dumpbin 导入表硬门禁），差别只在**怎么编**：
|
||||
CI 在 `windows-latest`（x64 宿主）上交叉编译到 `aarch64-pc-windows-msvc`，产物落在
|
||||
`target/aarch64-pc-windows-msvc/release`（由 `matrix.build_dir` 注入，脚本不硬编码路径）。
|
||||
GitHub 文档（2026）已把 `windows-11-arm` / `windows-11-vs2026-arm` 列为公开仓库**免费**的标准
|
||||
arm64 runner，原生路线可行；本流水线仍选交叉编译，因为①双 Windows 槽位共用同一套已验证镜像与
|
||||
工具链、②M50 的 dumpbin 定位链取的是 `Hostx64/x64/dumpbin.exe`（读 ARM64 PE 的导入表没问题），
|
||||
原生 ARM 宿主上那条链得再补 `Hostarm64` 分支——不为一个槽位放宽刚立的门禁。
|
||||
**M140 起在原生 `windows-11-arm` 上编**（GitHub 文档 2026 的 Standard runners 表明列该标签：4C/16G、
|
||||
公开仓库免费），产物落在 `target/release`（`matrix.build_dir` 注入，脚本不硬编码路径）。原路线是在
|
||||
`windows-latest` 上交叉编译到 `aarch64-pc-windows-msvc`，但**CI 上从未成功过一次**（v0.2.1 首次真跑即
|
||||
红在「ARM64 工具链体检」：x64 镜像上探不到 VC/SDK 的 ARM64 库），"双 Windows 共用一套镜像"的惯性理由
|
||||
因此不再成立。原生的附赠好处：宿主=产物架构，`ull --version` 冒烟**真跑**；M50 的 dumpbin 定位链补了
|
||||
`Hostarm64/arm64` 分支，并按 `RUNNER_ARCH` 只挑本机能执行的那族（x64 上不会挑到跑不起来的 arm64 二进制）。
|
||||
|
||||
运行时依赖与 x64 同表（UCRT 是 Win11 ARM 的系统组件，`+crt-static` 静态链 CRT，不需要可再发行包）。
|
||||
游戏侧如实说：**启动器原生运行**；Temurin 没有 windows-aarch64 产物，Microsoft OpenJDK 有该
|
||||
@@ -312,10 +312,10 @@ libxcb 条目数 = 0，只把 fontconfig 那 7 个 `.so` 放进 `LD_LIBRARY_PATH
|
||||
| `linux-arm64` stub 归档 | 成员 `unlucky-launcher-0.1.0-linux-arm64/{LICENSE,NOTICE,README.md,unlucky-launcher}`（旧连字符名，当次实测），权限 0644/0755、`uid=gid=0`、mtime 0、gzip 头 mtime 字段 `00 00 00 00`；连调两次 sha256 完全一致（`f949d0f5…`）→ 可复现规则与 x64 同源 |
|
||||
| `windows-x64` 原生回归 | `arch: … -> x64`、`smoke: ull.exe --version -> 0.1.0 (ok)`、产物 14.01 MiB、`sha256sum -c SHA256SUMS.txt` OK（这一次用的是当前工作树的二进制，与 §7.3 那次不是同一次构建，sha256 自然不同） |
|
||||
|
||||
**没在本地验证、只能由 CI 补的**：`windows-arm64` 的交叉链接与真实 ARM64 导入表、`linux-arm64` 在原生 arm64
|
||||
runner 上的真跑（本机连 `raw.githubusercontent.com` 都解析不了，查不到 runner 镜像里装没装 ARM64 的 MSVC 库）。
|
||||
`release.yml` 为此加了一道链接前体检（查 `libcmt.lib` 与 `um/arm64/kernel32.lib`，缺了直接给"加 `VC.Tools.ARM64`
|
||||
或改原生 runner"的提示）；merge 后重跑流水线，两槽位进 `SHA256SUMS.txt` 即算闭环。
|
||||
**没在本地验证、只能由 CI 补的**：`windows-arm64` 在 `windows-11-arm` 上的真实链接与 ARM64 导入表、
|
||||
`linux-arm64` 在原生 arm64 runner 上的真跑（本机既没有 ARM 机器，也连 `raw.githubusercontent.com` 都解析不了）。
|
||||
M140 保留了一道编译前体检（查 VC 的 `lib/arm64/libcmt.lib` 与 SDK 的 `um/arm64/kernel32.lib`，失败时把
|
||||
**实际探测到的目录**打印出来）；下次 tag 跑绿、两槽位进 `SHA256SUMS.txt` 即算闭环。
|
||||
|
||||
## 8. 发行合规
|
||||
|
||||
|
||||
Reference in new issue
Block a user