ci(release): M164 arm64 判定权交回编译器 + 发布名单守卫（不翻牌）
根因（拿到的真实证据，不是猜的）：v0.2.2（run 42322062879 / job 128248713926）与 v0.2.3 （run 42429017002 / job 128573547829）两份 check-run 注解逐字一致 —— 失败步骤是第 6 步 `Windows ARM64 工具链体检`，第 7 步 `cargo build` 状态 skipped。也就是说 v0.2.1~v0.2.3 五轮 全红都红在一个**编译前的启发式探针**上，真正的编译器/链接器一次都没说话。该探针的结论还与它 自己打印的快照矛盾：`SDK Lib 版本→um 架构: 10.0.22621.0→um:[arm,arm64,x64,x86,]` 明明在，却 同时报 `kernel32=缺失`（同一个 `find -path` 模式在本地合成目录树上命中）。runner 实况是 Windows 11 Arm64 + Visual Studio 2026 镜像，`VC.Tools.ARM64` 与 `Windows11SDK.22621/26100` 都装好了，M142 的 `setup.exe modify` 反倒返回非 0。 改： - release-build.yml：探针降级为「只取证」——vswhere 组件查询 + 各目录 `.lib` 计数 + arm64 `link.exe` 候选，一条 `::error::` 都不写、永不 exit 1；不再自动补装 VS。红绿只由 cargo/链接/静态 CRT 导入表门禁决定。cargo build 步给 arm64 显式备齐工具链： `rustup target add aarch64-pc-windows-msvc`、`vcvarsall.bat arm64` 取 `LIB`/`INCLUDE`、 vswhere 定位 arm64 `link.exe` 后导出 `CARGO_TARGET_AARCH64_PC_WINDOWS_MSVC_LINKER` （顺序不能反：只给链接器不给 LIB ⇒ LNK1181 kernel32.lib）。 - 新增 packaging/check_publish_slots.py（344 行，零依赖）：名单 ⇄ 产物**两个方向**。 声明了缺 GUI/CLI ⇒ `::error::` + exit 1；有产物没声明 ⇒ `::warning::` 明说未发布（M142 之后 这个方向是静默的，裁剪步只 echo 一行 drop:）。另有源码级断言（名单每项必须存在且 mode=ci、 运行期名单必须等于文件里那行）与 8 条 `--self-test` 注入回归。 - release-publish.yml：裁剪前插一步跑那个守卫，原来内联的齐全性循环搬进脚本（一套判据一处实现）； 重算 SHA256SUMS 的步骤只负责重算。 - release-guard.yml：PR 阶段跑守卫自测 + 源码级断言。 - 文档同步：release.yml / release-publish.yml / release-build.yml 头注释、packaging/README §12、 §1 矩阵、§3 构建与发布、§9 支持矩阵、§7.5 arm64 取证、release-notes.md、README/README.zh-CN 的产物矩阵与说明。口径统一为「arm64 构建取证中、未发布」，不写成已支持。 没做的（按 tower 裁决「方案乙」）：`PUBLISH_SLOTS` 本轮**不加回** arm64。arm64 从未产出过 PE、 本机也证不了，写进名单就等于拿 x64 的发布去赌它（M142 移出名单正是为避免这个事故）。下一 tag 的 CI 真出包后翻一行即可，守卫与 SHA256SUMS 自动跟着扩。 验证：workflow YAML 全部可被 PyYAML 解析；所有 `run:` 块过 `bash -n`；探针步在本机（无 VS/SDK） 实跑 exit 0 并打出实况注解；守卫 `--self-test` 8 条全绿、正反两个方向都在合成 dist 上实测过； check_release_semantics.py（含 --self-mutation）/ release_marker / make_manifest 自检全绿； cargo metadata 正常。**arm64 产物从未被构建过、也从未在真机跑过**——本机 `rustc --target aarch64-pc-windows-msvc` 直接撞上没有 MSVC 链接器（git-bash 的 GNU `link` 被当成 link.exe）， `cargo check --workspace --target aarch64-pc-windows-msvc` 也死在 aws-lc-sys 的 cc-rs 阶段 （GNU host 上没有该 target 的 C 编译器）。真实结论只能等下一 tag 的 CI。
This commit is contained in:
AskaEth committed
1 parent
15a19bb375
commit
e858664fca
13 files changed
+577
-120
No files matched your search
@@ -1,9 +1,11 @@
|
||||
name: Release / build（可复用）
|
||||
|
||||
# Release 流水线的**构建侧**（M145 拆分：`release.yml` 与 `packaging/README.md` 都顶到 400 行红线，下一处改动必越线）。
|
||||
# 本文件 = 拆分前 `.github/workflows/release.yml` 的 `build` job **逐字搬家**，唯一的改动是四个矩阵键换成同名入参：
|
||||
# M145 时本文件 = 拆分前 `.github/workflows/release.yml` 的 `build` job **逐字搬家**，改动只有四个矩阵键换成同名入参：
|
||||
# `matrix.slot` → `inputs.slot`、`matrix.os` → `inputs.os`、`matrix.build_dir` → `inputs.build_dir`、
|
||||
# `matrix.rustflags` → `inputs.rustflags`。其余 `name` / `if` / `env` / `run` / `uses` 与拆分前逐行相同。
|
||||
# `matrix.rustflags` → `inputs.rustflags`。
|
||||
# **M164 改了两步**（只这两步）：① `Windows ARM64 工具链体检` → `工具链取证`（不再 exit 1，判定权交回编译器；
|
||||
# 理由见该步上方的长注释）；② `cargo build` 步给 arm64 槽位显式备齐 target / `LIB`+`INCLUDE` / arm64 `link.exe`。
|
||||
# 矩阵**仍由调用方** `release.yml` 的 `plan` job 生成并在外层展开（矩阵不能带 `if`，`strategy` 可读 `needs`），
|
||||
# 本文件只跑**单个槽位**，不持有槽位表 —— 改槽位只改 `release.yml` 里那一处。
|
||||
# `env` 必须在被调方重复声明：**被调工作流不继承调用方的 workflow 级 `env`**（CARGO_TERM_COLOR / RUST_BACKTRACE
|
||||
@@ -67,64 +69,56 @@ jobs:
|
||||
- uses: dtolnay/rust-toolchain@stable
|
||||
- uses: Swatinem/rust-cache@v2
|
||||
|
||||
# （M141/M142）windows-arm64 跑在**原生** `windows-11-arm` 上，本步查这台机器上 ARM64 库齐不齐：`+crt-static`
|
||||
# 要 MSVC 的 `lib/arm64/libcmt.lib`，链接要 SDK 的 `um/arm64/kernel32.lib`。诊断**只走注解**（job 日志下载要
|
||||
# token 我们没有，check-run 注解不用；每条一行，多行会被拼成一行截断，每步 error 注解上限 10 条）。
|
||||
# **M142 修本步的自毁 bug**：`shell: bash` 实为 `bash -eo pipefail`，脚本里的 `set -uo pipefail` **关不掉** -e——
|
||||
# M141 死在 `vc_lib=$(find 不存在的根 | head -n1)`（pipefail 把 find 的非零带进赋值、errexit 当场退出），
|
||||
# **一条注解都没打**，上一轮只剩 `Process completed with exit code 1.`。四条规矩：① 显式 `set +e`；② 每处探测
|
||||
# 自带 `|| true`；③ 问题记进 ERRORS 而不当场退出；④ 快照先打完、再由显式 `exit` 定红绿。门禁不降级（缺了就
|
||||
# 就地补装再判），但 **arm64 红不挡发布**（PUBLISH_SLOTS 已无它），本槽位只取证。
|
||||
- name: Windows ARM64 工具链体检（红不挡发布，只取证）
|
||||
# （M141/M142 → **M164 判定权移交**）windows-arm64 跑在**原生** `windows-11-arm` 上。本步**只取证，不判定**：
|
||||
# M141/M142 的版本用 `find` 猜 SDK 的 `um/arm64/kernel32.lib` 在不在，猜缺就 `exit 1` —— 结果 v0.2.1~v0.2.3
|
||||
# 五轮全红在**这一步**、下面 `cargo build` 一次都没跑过（第 7 步永远 skipped），"arm64 修不好"始终是探针给的
|
||||
# 结论、不是编译器给的。而它跟自己打的快照自相矛盾：v0.2.3 的注解原文是
|
||||
# `[arm64sdk] SDK Lib 版本→um 架构: 10.0.22621.0→um:[arm,arm64,x64,x86,] 10.0.26100.0→um:[arm64,x64,x86,]`
|
||||
# 同一份注解里却报 `kernel32=缺失`（同一个 `find` 模式在本地合成目录树上命中，故这条路本身不可靠）。
|
||||
# M164 把红绿交回编译器与链接器：本步只打印实况（vswhere 组件查询 / 目录里 .lib **计数** / arm64 link.exe
|
||||
# 路径），一条 `::error::` 都不写、永不 `exit 1`；红不红由 `cargo build` 与静态 CRT 导入表门禁决定。
|
||||
# 也不再自动补装：runner 镜像是 Windows 11 Arm64 + Visual Studio 2026（`windows-11-arm` 自 2026-09 切到 VS2026，
|
||||
# VS 在 `C:\Program Files\Microsoft Visual Studio\18\Enterprise`），其镜像清单
|
||||
# （actions/runner-images 的 `images/windows/Windows11-VS2026-Arm64-Readme.md`）里 `VC.Tools.ARM64`、
|
||||
# `Windows11SDK.26100`、`Windows11SDK.22621` 三件都已装好；M142 那次 `setup.exe modify` 反倒返回非 0。
|
||||
# 注解仍每条一行（job 日志下载要 token，check-run 注解不用；多行会被拼成一行截断）。
|
||||
- name: Windows ARM64 工具链取证（只打印实况，红绿交给编译器）
|
||||
if: inputs.slot == 'windows-arm64'
|
||||
shell: bash
|
||||
run: |
|
||||
set +e; set -uo pipefail; ERRORS=() # -e 由 runner 命令行注入，只能显式关
|
||||
say() { printf '::%s::[arm64sdk] %s\n' "$1" "$2"; [ "$1" = error ] && ERRORS+=("$2"); return 0; }
|
||||
vs=("C:/Program Files/Microsoft Visual Studio" "C:/Program Files (x86)/Microsoft Visual Studio")
|
||||
# SDK 根要放宽：新版装 `(x86)`、也有装 `Program Files`；老安装器把 lib 留在 Microsoft SDKs；
|
||||
# VS 自己还带一份「SDK in VS」（`<VS>/Windows Kits/10/Lib`），用 vswhere 定位后追加。
|
||||
sdk=("C:/Program Files (x86)/Windows Kits/10/Lib" "C:/Program Files/Windows Kits/10/Lib"
|
||||
"C:/Program Files (x86)/Microsoft SDKs/Windows/v10.0A/Lib")
|
||||
inst="C:/Program Files (x86)/Microsoft Visual Studio/Installer"; vspath=""
|
||||
[ -x "$inst/vswhere.exe" ] && vspath=$("$inst/vswhere.exe" -latest -products '*' -property installationPath 2>/dev/null | head -n1 || true)
|
||||
[ -n "$vspath" ] && sdk+=("${vspath//\\//}/Windows Kits/10/Lib")
|
||||
# 下面两个探测正是 M141 断气处（find 起点不存在 → 非 0 → `| head` 的 pipefail 带进赋值 → errexit），故处处
|
||||
# `|| true`：探不到就是「没找到」，由结论下判断，不许由它决定进程生死。
|
||||
scan() { vc_lib=$(find "${vs[@]}" -maxdepth 11 -type f -path '*/VC/Tools/MSVC/*/lib/arm64/libcmt.lib' 2>/dev/null | head -n1 || true)
|
||||
sdk_lib=$(find "${sdk[@]}" -maxdepth 6 -type f -path '*/um/arm64/kernel32.lib' 2>/dev/null | head -n1 || true); }
|
||||
build=$(ls "${sdk[@]}" 2>/dev/null | grep -oE '^10\.0\.[0-9]+' | cut -d. -f3 | sort -u | tail -n1 || true)
|
||||
scan
|
||||
# 快照固定 4 行，**无论齐不齐都先打完**：齐了用 notice（绿跑也留证据 = 探测本身没坏），缺了用 error。
|
||||
sev=error; [ -n "$vc_lib" ] && [ -n "$sdk_lib" ] && sev=notice
|
||||
say "$sev" "探测根: $(for d in "${vs[@]}" "${sdk[@]}"; do [ -d "$d" ] && printf '%s=有 ' "$d" || printf '%s=无 ' "$d"; done)vswhere=$([ -x "$inst/vswhere.exe" ] && echo 有 || echo 无) vspath=${vspath:-<空>}"
|
||||
v=""
|
||||
for d in "${sdk[@]}"; do [ -d "$d" ] || continue
|
||||
for t in "$d"/*/; do [ -d "$t" ] && v+="$(basename "$t")→um:[$(ls "$t/um" 2>/dev/null | tr '\n' ',')] "; done
|
||||
set +e; set -uo pipefail # -e 由 runner 命令行注入，只能显式关
|
||||
say() { printf '::%s::[arm64sdk] %s\n' "$1" "$2"; return 0; }
|
||||
shopt -s nullglob # 计数走 glob 不走 find：find 的管道 + errexit 正是 M141 的死因
|
||||
vswhere="C:/Program Files (x86)/Microsoft Visual Studio/Installer/vswhere.exe"
|
||||
[ -x "$vswhere" ] || say warning "找不到 vswhere（$vswhere）：下面会是 0 命中，那不代表工具链缺东西"
|
||||
# ① 组件：用 vswhere 自己的 `-requires`（权威查询），不拿「某个文件名存在」当替身。
|
||||
for comp in Microsoft.VisualStudio.Component.VC.Tools.ARM64 \
|
||||
Microsoft.VisualStudio.Component.Windows11SDK.26100 \
|
||||
Microsoft.VisualStudio.Component.Windows11SDK.22621; do
|
||||
hit=""
|
||||
[ -x "$vswhere" ] && hit=$("$vswhere" -latest -products '*' -requires "$comp" -property installationPath 2>/dev/null | head -n1 || true)
|
||||
if [ -n "$hit" ]; then say notice "组件 $comp: 已装（$hit）"
|
||||
else say warning "组件 $comp: 未装 / 这台 VS 不认这个 id（继续看下面的实际 .lib 计数）"; fi
|
||||
done
|
||||
say "$sev" "SDK Lib 版本→um 架构: ${v:-<没有任何版本目录>}（SDK build=${build:-未探到}）"
|
||||
v=""
|
||||
while IFS= read -r t; do v+="$(basename "$(dirname "$t")")→[$(ls "$t" 2>/dev/null | tr '\n' ',')] "; done \
|
||||
< <(find "${vs[@]}" -maxdepth 7 -type d -path '*/VC/Tools/MSVC/*/lib' 2>/dev/null | head -n4)
|
||||
say "$sev" "MSVC lib/ 架构: ${v:-<无 MSVC lib 目录>}"
|
||||
say "$sev" "关键库: libcmt=${vc_lib:-缺失} kernel32=${sdk_lib:-缺失}"
|
||||
if [ "$sev" = notice ]; then echo "ARM64 工具链齐: vc=$vc_lib sdk=$sdk_lib"; exit 0; fi
|
||||
# 补装：VS 安装器就地 modify（门禁不降级：先补再判）。组件 ID 随 VS 大版本不同；**优先补一个尚未装上的
|
||||
# SDK 版本**——同版本重装是 no-op，补不出 arm64 子目录。补装失败不致命，重探与结论给真相。
|
||||
id=Microsoft.VisualStudio.Component.Windows11SDK.$([ "$build" = "26100" ] && echo 22621 || echo 26100)
|
||||
[ "$build" = "19041" ] && id=Microsoft.VisualStudio.Component.Windows10SDK.20348
|
||||
adds=""; [ -n "$vc_lib" ] || adds+="Microsoft.VisualStudio.Component.VC.Tools.ARM64 "; [ -n "$sdk_lib" ] || adds+="$id"
|
||||
if [ -x "$inst/setup.exe" ] && [ -n "$vspath" ]; then
|
||||
say error "补装: $vspath ← ${adds}（已装 SDK build=${build:-未装}）"
|
||||
timeout 1200 "$inst/setup.exe" modify --installPath "$vspath" --quiet --norestart --nocache --wait \
|
||||
--add ${adds} || say error "补装返回非 0：组件 ID 可能不被这台 VS 认（见下一条结论）"
|
||||
scan
|
||||
else say error "补装跳过: 无 vs_installer 或没定位到 VS 安装路径（vspath=${vspath:-<空>}）"; fi
|
||||
if [ -z "$vc_lib" ] || [ -z "$sdk_lib" ]; then
|
||||
say error "结论: 仍缺（libcmt=${vc_lib:-缺失} kernel32=${sdk_lib:-缺失}），共记 ${#ERRORS[@]} 条探测问题；门禁红、不摘 arm64——本槽位不在 PUBLISH_SLOTS 里，x64 照发"
|
||||
exit 1
|
||||
fi
|
||||
echo "补装后齐全: vc=$vc_lib sdk=$sdk_lib"
|
||||
# ② 实况计数：`+crt-static` 要 VC 的 `lib/arm64/libcmt.lib`，链接要 SDK 的 `um/arm64/*.lib`。
|
||||
for root in "C:/Program Files/Microsoft Visual Studio" "C:/Program Files (x86)/Microsoft Visual Studio"; do
|
||||
hits=( "$root"/*/*/VC/Tools/MSVC/*/lib/arm64/libcmt.lib )
|
||||
say notice "VC $root → lib/arm64/libcmt.lib ${#hits[@]} 个${hits[0]:+（首个 ${hits[0]}）}"
|
||||
done
|
||||
for root in "C:/Program Files (x86)/Windows Kits/10/Lib" "C:/Program Files/Windows Kits/10/Lib"; do
|
||||
[ -d "$root" ] || { say notice "SDK $root：不存在"; continue; }
|
||||
for ver in "$root"/*/; do
|
||||
libs=( "$ver"um/arm64/*.lib )
|
||||
say notice "SDK $(basename "$ver") → um/arm64/*.lib ${#libs[@]} 个"
|
||||
done
|
||||
done
|
||||
# ③ arm64 链接器候选：宿主 arm64 的优先（原生），x64 托管的次之。下面 cargo 步会显式导出它。
|
||||
for p in 'VC/Tools/MSVC/*/bin/Hostarm64/arm64/link.exe' 'VC/Tools/MSVC/*/bin/Hostx64/arm64/link.exe'; do
|
||||
hit=""
|
||||
[ -x "$vswhere" ] && hit=$("$vswhere" -latest -products '*' -find "$p" 2>/dev/null | head -n1 || true)
|
||||
say notice "link.exe 候选 $p → ${hit:-未命中}"
|
||||
done
|
||||
echo "取证完毕：本步不判红；arm64 的结论只看下面的 cargo build / 链接 / 导入表门禁"
|
||||
|
||||
# M118（D26）：**Slint 版停发** —— GUI 只有 `unlucky-launcher-iced`（`crates/app` 已 exclude，不进 workspace）。
|
||||
# 产物名由 make_artifacts.py 的 `asset_stem()` 生成 `<名字>_<版本号>_<平台>_<架构>`；不传 `--target`（M140 起全原生）。
|
||||
@@ -132,14 +126,64 @@ jobs:
|
||||
# 官方产物自带微软登录所需的配置，装完即可登录；运行期同名环境变量仍优先于它，可覆盖。
|
||||
# 值来自仓库 Secret（不进 git 文件）；Secret 没配时这里是空串，client_id.rs 把空白当「没配」，
|
||||
# 于是非官方构建不烘 id。想自己烘一份就从源码构建：`ULL_MSA_CLIENT_ID=<id> cargo build`。
|
||||
# （M164）arm64 槽位在编译前把工具链**显式**备齐，不再依赖「runner 反正自带」这种默契：
|
||||
# ① `rustup target add aarch64-pc-windows-msvc`：宿主机本来就是 aarch64-pc-windows-msvc，这句在原生
|
||||
# runner 上是幂等 no-op；它把「缺 std」这类失败挡在编译前（缺 target 时 rustc 只会说找不到 crate std）；
|
||||
# ② MSVC 的 `LIB` / `INCLUDE` 用微软自己的 `vcvarsall.bat arm64` 取（**不手搓路径**：少一个目录就是
|
||||
# LNK1181），本步 `export` 一次、同时写进 `$GITHUB_ENV` 供下游 dumpbin / 打包步；
|
||||
# ③ arm64 的 `link.exe` 用 vswhere 定位后显式导出 `CARGO_TARGET_AARCH64_PC_WINDOWS_MSVC_LINKER`
|
||||
# （Hostarm64 原生优先、Hostx64 次之）。**②必须先于③**：只覆盖链接器而不给 LIB，rustc 会在
|
||||
# `link.exe` 里撞 `LNK1181: cannot open input file 'kernel32.lib'`——那正是我们要定位的错误，不是要制造的错误。
|
||||
# ①②③ 全是「定位不到就打印原因继续」，不用启发式决定红绿：真缺工具链时让链接器自己报出来。
|
||||
- name: cargo build --release --locked
|
||||
shell: bash
|
||||
env:
|
||||
RUSTFLAGS: ${{ inputs.rustflags }}
|
||||
ULL_MSA_CLIENT_ID: ${{ secrets.ULL_MSA_CLIENT_ID }}
|
||||
SLOT: ${{ inputs.slot }}
|
||||
BUILD_DIR: ${{ inputs.build_dir }}
|
||||
run: |
|
||||
set -euo pipefail
|
||||
echo "host=$(rustc -vV | sed -n 's/^host: //p') slot=$SLOT build_dir=$BUILD_DIR"
|
||||
if [ "$SLOT" = "windows-arm64" ]; then
|
||||
rustup target add aarch64-pc-windows-msvc
|
||||
rustup target list --installed
|
||||
vswhere="C:/Program Files (x86)/Microsoft Visual Studio/Installer/vswhere.exe"
|
||||
if [ -x "$vswhere" ]; then
|
||||
vcvars=$("$vswhere" -latest -products '*' -find 'VC/Auxiliary/Build/vcvarsall.bat' 2>/dev/null | head -n1 || true)
|
||||
dump=""
|
||||
if [ -n "$vcvars" ]; then
|
||||
# `cmd //c` 是 git-bash 调 cmd 的安全写法（`//c` 不会被当成路径）；`set` 打出全量环境。
|
||||
dump=$(cmd //c "\"${vcvars//\//\\}\" arm64 >nul 2>&1 && set" 2>/dev/null | tr -d '\r') || dump=""
|
||||
fi
|
||||
for key in LIB INCLUDE; do
|
||||
value=$(printf '%s\n' "$dump" | sed -n "s/^${key}=//p" | head -n1)
|
||||
if [ -n "$value" ]; then
|
||||
export "$key=$value"
|
||||
printf '%s=%s\n' "$key" "$value" >> "$GITHUB_ENV"
|
||||
echo "env $key=${value:0:90}…（${#value} 字符）"
|
||||
else
|
||||
echo "::warning::[arm64] 没拿到 $key（vcvarsall=${vcvars:-未定位}）：留空交给 rustc 自己探测 VS"
|
||||
fi
|
||||
done
|
||||
found=""
|
||||
for p in 'VC/Tools/MSVC/*/bin/Hostarm64/arm64/link.exe' 'VC/Tools/MSVC/*/bin/Hostx64/arm64/link.exe'; do
|
||||
hit=$("$vswhere" -latest -products '*' -find "$p" 2>/dev/null | head -n1 || true)
|
||||
if [ -n "$hit" ]; then found=${hit//\\//}; break; fi
|
||||
done
|
||||
if [ -n "$found" ]; then
|
||||
export CARGO_TARGET_AARCH64_PC_WINDOWS_MSVC_LINKER="$found"
|
||||
printf 'CARGO_TARGET_AARCH64_PC_WINDOWS_MSVC_LINKER=%s\n' "$found" >> "$GITHUB_ENV"
|
||||
echo "linker: $found"
|
||||
else
|
||||
echo "::warning::[arm64] 没定位到 arm64 link.exe：让 rustc 自己找（真的失败时错误里会带路径）"
|
||||
fi
|
||||
else
|
||||
echo "::warning::[arm64] 没有 vswhere：target 已加，链接器交给 rustc 自己探测"
|
||||
fi
|
||||
fi
|
||||
cargo build --release --locked --bin unlucky-launcher-iced --bin ull
|
||||
ls -l "$BUILD_DIR"/unlucky-launcher-iced* "$BUILD_DIR"/ull*
|
||||
|
||||
- name: Windows 单文件自检（导入表不得出现 VC++ 可再发行 DLL）
|
||||
if: runner.os == 'Windows'
|
||||
@@ -239,9 +283,11 @@ jobs:
|
||||
if-no-files-found: error
|
||||
retention-days: 14
|
||||
|
||||
# （M142）arm64 若红在别的步骤（cargo / 打包 / 导入表门禁），也要有一条注解说清「红在哪」和「不挡发布」——
|
||||
# 只剩一句 `Process completed with exit code 1.` 的教训见上一条体检步骤。
|
||||
# （M142/M164）arm64 若红在别的步骤（cargo / 链接 / 打包 / 导入表门禁），也要有一条注解说清「红在哪」和
|
||||
# 「不挡发布」——只剩一句 `Process completed with exit code 1.` 的教训见上面那条体检步骤。
|
||||
# M164 起本槽位的红**只可能来自真实构建链路**（体检已降级为取证、永不 exit 1），所以这条注解同时也是
|
||||
# 「arm64 到底能不能编出来」的答案所在：红了就把上面的编译器/链接器原文当根因，别再回去改体检。
|
||||
- name: arm64 失败收尾注解（红不挡发布）
|
||||
if: failure() && inputs.slot == 'windows-arm64'
|
||||
shell: bash
|
||||
run: echo "::error::[arm64] 本槽位已红（失败步骤见本 job 的步骤名与上面各条注解）；PUBLISH_SLOTS 当前只有 windows-x64 ⇒ 本次 Release 仍照发 x64，arm64 产物不进 Release"
|
||||
run: echo "::error::[arm64] 本槽位已红，失败步骤见本 job 的步骤名（M164 起只会是 cargo build / 链接 / 导入表门禁 / 打包，体检步不再判红）；PUBLISH_SLOTS 当前只有 windows-x64 ⇒ 本次 Release 仍照发 x64，arm64 产物不进 Release"
|
||||
@@ -16,6 +16,12 @@ name: Release guard
|
||||
# 为什么不并进 guards.yml：那份文件已经 398 行（400 行红线），再挂一个 job 必越线。
|
||||
# 改 `release.yml` 的 prerelease 输入 / 改那段 `gh release` 时，先跑
|
||||
# `python3 packaging/check_release_semantics.py`（本机可用 `python`，脚本会自己找 bash）。
|
||||
#
|
||||
# （M164）同一个 job 还挂**发布名单守卫** `packaging/check_publish_slots.py`：`PUBLISH_SLOTS` 与槽位表/产物
|
||||
# 必须对得上。PR 阶段跑源码级断言（名单非空、每项都是 `release.yml` 槽位表里的 `mode: ci` 档）——
|
||||
# 名单里写错一个字此前只会表现为「Release 侧一个也不匹配、齐全性检查红在别处」，根因要翻两层日志；
|
||||
# `--self-test` 再注入 8 条回归（缺资产 / 拼错 / 声明了 probe 档 / 名单声明了没产物 / 有产物没声明）证明它会红。
|
||||
# 发布侧那道「产物 ⇄ 名单」的运行时断言在 `release-publish.yml`（同一份脚本，`--dist`）。
|
||||
|
||||
on:
|
||||
push:
|
||||
@@ -38,3 +44,7 @@ jobs:
|
||||
run: python3 packaging/check_release_semantics.py
|
||||
- name: 变异自测（守门抓不抓得住回归）
|
||||
run: python3 packaging/check_release_semantics.py --self-mutation
|
||||
- name: 发布名单守卫自测（声明⇒必须有产物 / 有产物没声明⇒显式警告）
|
||||
run: python3 packaging/check_publish_slots.py --self-test
|
||||
- name: 发布名单与矩阵槽位一致（拼错字 / 声明了 probe 档 当场红）
|
||||
run: python3 packaging/check_publish_slots.py
|
||||
@@ -4,6 +4,8 @@ name: Release / publish（可复用）
|
||||
# job **逐字搬家**：裁剪白名单外的槽位产物、重算全量 `SHA256SUMS.txt`、渲染 `packaging/release-notes.md` 模板、
|
||||
# `gh release create/edit` 的同 tag 幂等，全部照旧。留在调用方 `release.yml` 的只有三件事：`needs: build`、
|
||||
# tag 门禁 `if: always() && !cancelled() && github.ref_type == 'tag'`、以及 `permissions: contents: write` 的授予。
|
||||
# **M164 新增一步**（其余仍照旧）：下载 artifact 之后、裁剪之前的「发布名单守卫」`packaging/check_publish_slots.py`
|
||||
# —— 原来那份「名单内少一档就 fail」的内联循环搬进那个脚本，并补上反方向（有产物没声明 ⇒ `::warning::` 未发布）。
|
||||
# 与拆分前的三处等价改写（都只涉及"从哪里读"，不涉及行为）：
|
||||
# ① `secrets.GITHUB_TOKEN` → 本文件声明的入参 secret `PUBLISH_TOKEN`（调用方透传 `secrets.GITHUB_TOKEN`）。
|
||||
# 可复用工作流**拿不到**调用方未显式传入的 secret，写 `secrets.GITHUB_TOKEN` 会静默为空 → gh 401。
|
||||
@@ -38,10 +40,17 @@ jobs:
|
||||
contents: write
|
||||
env:
|
||||
# ── 发布白名单：唯一决定「哪几个槽位进 Release」的开关（空格分隔，键同 matrix.slot）──
|
||||
# **M142 起只有 `windows-x64`**：arm64 连试四轮未走通，而下面齐全性检查是「名单内少一档就 fail」——名字挂着
|
||||
# arm64 就等于 x64 编成功也发不出去。故把它移出名单：它照留在矩阵里跑取证（诊断注解是将来修它的唯一证据），
|
||||
# **红了不挡发布**。**可逆**：arm64 修好后把键加回这一行即可（齐全性检查与 SHA256SUMS 自动跟着扩），再同步
|
||||
# README §1/§9 与 release-notes.md 两张表。四档 Linux/macOS 仍未验证，默认连构建都不跑（M139）。
|
||||
# **M142 起只有 `windows-x64`**：arm64 连试四轮未走通，而齐全性检查是「名单内少一档就 fail」——名字挂着
|
||||
# arm64 就等于 x64 编成功也发不出去。故把它移出名单：它照留在矩阵里跑取证，**红了不挡发布**。
|
||||
# （M164）**为什么现在还只有 x64**：arm64 五轮全红其实都红在一个误判的编译前体检步（见 release-build.yml
|
||||
# 顶部那段），真正的 cargo/link 一次都没跑过；M164 把那个门禁拆了、判定权交回编译器，但「arm64 能不能编出
|
||||
# PE」只能由**下一 tag 的 CI** 证明，本机没有 ARM64 真机/工具链证不了。在拿到那次绿之前把 arm64 写进来，
|
||||
# 等于拿 x64 的发布去赌它 —— 同一个事故不演第二遍（tower M164 裁决）。
|
||||
# **可逆，且只是一行**：那句 CI 真出包之后把键加回这一行（`"windows-x64 windows-arm64"`），齐全性检查与
|
||||
# SHA256SUMS 自动跟着扩，再同步 README §1/§9 与 release-notes.md 两张表。
|
||||
# 判据不再靠注释保证：`packaging/check_publish_slots.py`（下面第二个 step 跑它；PR 阶段由 release-guard.yml
|
||||
# 跑同一份脚本）两个方向都查——声明了缺产物 ⇒ `::error::` + exit 1；有产物但没声明 ⇒ `::warning::` 明说未发布。
|
||||
# 四档 Linux/macOS 仍未验证，默认连构建都不跑（M139）。
|
||||
PUBLISH_SLOTS: "windows-x64"
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
@@ -51,6 +60,17 @@ jobs:
|
||||
path: dist
|
||||
merge-multiple: true
|
||||
|
||||
# （M164）发布名单守卫：**声明了就必须有产物**（名单内某个槽位缺 GUI 或 CLI 就红，少一档不发版），
|
||||
# 反方向的「产物在、名单没声明」则打 `::warning::` 明说未发布 —— M142 之后那个方向是**静默**的（裁剪步只
|
||||
# echo 一行 `drop:`，没有注解、也没有非零退出），一个真编出来的 arm64 会被就地 `rm` 掉而没人知道。
|
||||
# 判据全在 `packaging/check_publish_slots.py`：同一份代码本地可跑，`--self-test` 注入 8 条回归断言每条都红。
|
||||
# 它跑在**裁剪前**的全量集上（裁剪只删名单外的文件），所以是原来「裁剪后再查」那次检查的严格超集。
|
||||
- name: 发布名单守卫（声明 ⇒ 必须有产物；有产物没声明 ⇒ 显式未发布）
|
||||
shell: bash
|
||||
run: |
|
||||
set -euo pipefail
|
||||
python3 packaging/check_publish_slots.py --dist dist --slots "$PUBLISH_SLOTS"
|
||||
|
||||
- name: 裁掉白名单外的槽位产物（构建取证 ≠ 发布）
|
||||
shell: bash
|
||||
run: |
|
||||
@@ -67,30 +87,20 @@ jobs:
|
||||
echo "publish: $base"
|
||||
;;
|
||||
*)
|
||||
echo "drop: $base（$platform_arch 不在发布白名单：四档未验证 / arm64 待修；仍留在 dist-<slot> artifact 里取证）"
|
||||
echo "drop: $base（$platform_arch 不在发布白名单：四档未验证 / arm64 待下一 tag 验证；仍留在 dist-<slot> artifact 里取证）"
|
||||
rm -f "$f"
|
||||
;;
|
||||
esac
|
||||
done
|
||||
|
||||
- name: 发布白名单齐全性 + 重算全量 SHA256SUMS
|
||||
- name: 重算全量 SHA256SUMS
|
||||
shell: bash
|
||||
run: |
|
||||
set -euo pipefail
|
||||
ls -l dist
|
||||
# 白名单内槽位必须**全齐**才发版（宁可不出 Release，也不出少一档的 Release）。每个槽位都要 GUI 与 CLI 两个
|
||||
# 资产——只按「槽位名出现过」判会被其中一个掩盖；比较用下划线形态（资产名自 D49 起是 `..._windows_x64.exe`）。
|
||||
# M142 后白名单只剩 x64 一档：arm64 缺产物不再拦发布，但 x64 自己缺 GUI 或 CLI 照样在这里 fail。
|
||||
for slot in $PUBLISH_SLOTS; do
|
||||
stem=${slot//-/_}
|
||||
for prefix in unlucky-launcher ull; do
|
||||
if ! compgen -G "dist/${prefix}_*_${stem}*" >/dev/null; then
|
||||
echo "::error::发布白名单缺产物：$prefix / $slot"
|
||||
exit 1
|
||||
fi
|
||||
done
|
||||
done
|
||||
# 各槽位各写一份 SHA256SUMS.txt，合并后只有一份是真的 —— 在 Release 侧按已发布的资产重算。
|
||||
# 齐全性（名单内每个槽位 GUI 与 CLI 都要在）**已由上上步的「发布名单守卫」断言**，且那一步看的是裁剪前的
|
||||
# 全量集 —— 同一套规则只留一份实现，免得两处判据漂开。这里只负责重算摘要：各槽位各写一份 SHA256SUMS.txt，
|
||||
# 合并后只有一份是真的，故在 Release 侧按已发布的资产重算。
|
||||
cd dist
|
||||
rm -f SHA256SUMS.txt
|
||||
sha256sum unlucky-launcher_* ull_* > SHA256SUMS.txt
|
||||
|
||||
@@ -3,19 +3,25 @@ name: Release
|
||||
# 发布流水线：tag `v*` → **只构建两个 Windows 槽位**（各自原生 `windows-latest` / `windows-11-arm`）→ 单文件产物 +
|
||||
# SHA256SUMS → artifact + GitHub Release。**push tag 默认创建稳定版**（M163：不带 `--prerelease`，否则
|
||||
# `releases/latest` 永远 404、自更新通道取不到清单）；同 tag 重跑幂等（覆盖资产与说明、不 create、不碰标记）。
|
||||
# **构建 ≠ 发布**：只有 `PUBLISH_SLOTS` 里的槽位才进 Release 与 SHA256SUMS ——**M142 起只有 `windows-x64`**（arm64 连试
|
||||
# 四轮未成，仍留矩阵里取证、红了不挡 x64 发布；它修好后把键加回那一行即可）。四档 Linux/macOS 从未验证，默认连构建都
|
||||
# 不跑（M139：省配额、不留红叉）；整表六槽位取证走 `gh workflow run release.yml -f all_slots=true`（槽位表在 `plan`）。
|
||||
# **构建 ≠ 发布**：只有 `PUBLISH_SLOTS` 里的槽位才进 Release 与 SHA256SUMS ——**M142 起只有 `windows-x64`**（arm64 仍留
|
||||
# 矩阵里取证、红了不挡 x64 发布）。**M164 的更正**：arm64 那五轮红其实全红在一个误判的编译前体检步（cargo/link 一次
|
||||
# 都没跑过，见 `release-build.yml` 顶部），该门禁已拆、判定权交回编译器；但「arm64 能不能出 PE」只能由**下一 tag 的
|
||||
# CI** 证明，故名单仍只列 x64（tower 裁决：不拿 x64 的发布去赌一个没验证过的槽位）。真出包之后把键加回那一行即可。
|
||||
# 四档 Linux/macOS 从未验证，默认连构建都不跑（M139：省配额、不留红叉）；整表六槽位取证走
|
||||
# `gh workflow run release.yml -f all_slots=true`（槽位表在 `plan`）。
|
||||
# 名单 ⇄ 产物两个方向都有守卫（M164）：`packaging/check_publish_slots.py`（PR 阶段在 release-guard.yml，发布侧在
|
||||
# release-publish.yml 的 `--dist` 模式）——声明了缺产物 ⇒ 红；有产物没声明 ⇒ `::warning::` 明说未发布。
|
||||
# 契约唯一真相源 packaging/README.md，打包本体 packaging/make_artifacts.py（本地与 CI 同一份脚本）。`inputs.prerelease`
|
||||
# 只在 **tag ref** 上 dispatch 才可达（跑 tag 得 `gh workflow run release.yml --ref v0.2.1`）；分支 ref 的 dispatch 与
|
||||
# push 一样被 release job 的 `if: github.ref_type == 'tag'` 挡在发布之外。
|
||||
#
|
||||
# M145 拆分（本文件与 packaging/README.md 都已顶到 400 行红线，下一处改动必越线）：本文件只留**触发 + 槽位表 + 编排**，
|
||||
# 两个 job 的实体各搬一份可复用工作流（`workflow_call`），步骤逐字未改：
|
||||
# - `.github/workflows/release-build.yml` = 原 `build` job 全流程（Linux 依赖 / arm64 工具链体检 / cargo build /
|
||||
# 静态 CRT 导入表门禁 / 打包 / 归档自检 / 上传 artifact / arm64 收尾注解），矩阵键换成同名 `inputs.*`。
|
||||
# - `.github/workflows/release-build.yml` = 原 `build` job 全流程（Linux 依赖 / arm64 工具链取证（M164 起只取证）/
|
||||
# cargo build / 静态 CRT 导入表门禁 / 打包 / 归档自检 / 上传 artifact / arm64 收尾注解），矩阵键换成同名 `inputs.*`。
|
||||
# - `.github/workflows/release-publish.yml` = 原 `release` job 全流程（`PUBLISH_SLOTS` 白名单 / 裁剪 / 重算
|
||||
# SHA256SUMS / 渲染说明 / `gh release` 幂等），`secrets.GITHUB_TOKEN` 改为显式透传的 secret。
|
||||
# （M164 在裁剪前插了一步「发布名单守卫」，故它是 7 步而不是搬家时的 6 步。）
|
||||
# `on` / `env` / `permissions` / `concurrency` 与 `plan` 的槽位表**一字未动**。
|
||||
|
||||
on:
|
||||
@@ -72,9 +78,11 @@ jobs:
|
||||
SLOTS = [
|
||||
# Windows x64：MSVC + 静态 CRT（+crt-static）→ exe 不依赖 VC++ 可再发行包，双击即用的单文件。
|
||||
dict(slot="windows-x64", os="windows-latest", build_dir="target/release", rustflags="-C target-feature=+crt-static", mode="ci"),
|
||||
# Windows arm64：**原生** `windows-11-arm`（4C/16G，公开仓库免费；GitHub 文档的 Standard runners 也列
|
||||
# `windows-11-vs2026-arm`）。M140 前是在 windows-latest 上交叉，**CI 从未成功过一次**（v0.2.1 首跑红在
|
||||
# 工具链体检，M141/M142 在此修）。原生还让 `ull --version` 冒烟真跑，dumpbin 走 Hostarm64 分支。
|
||||
# Windows arm64：**原生** `windows-11-arm`（4C/16G，公开仓库免费）。该标签自 2026-09 起是
|
||||
# **Windows 11 Arm64 + Visual Studio 2026** 镜像（VS 在 `C:\Program Files\Microsoft Visual Studio\18`），
|
||||
# 镜像清单里 `VC.Tools.ARM64` 与 `Windows11SDK.22621/26100` 都装好了。M140 前是在 windows-latest 上交叉；
|
||||
# v0.2.1~v0.2.3 的红全红在 M141/M142 那个**编译前体检**步（cargo 永远 skipped），M164 已把它降级为只取证。
|
||||
# 原生还让 `ull --version` 冒烟真跑，dumpbin 走 Hostarm64 分支。
|
||||
dict(slot="windows-arm64", os="windows-11-arm", build_dir="target/release",
|
||||
rustflags="-C target-feature=+crt-static", mode="ci"),
|
||||
# ↓ 四档**未验证，不纳入 CI**：从未真构建成功、也没在真机跑过，默认一个都不编；`all_slots=true` 时照编
|
||||
|
||||
Reference in new issue
Block a user