AskaEth/Unlucky-Launcher
1
0 Fork 0
Code Issues Pull Requests Actions 5 Packages Projects Releases Wiki Activity
Files
2813e2984c07282405aac27896156479769f5b6f
Unlucky-Launcher/packaging/docs/artifacts-and-version.md
T
AskaEth 2813e2984c ci(m184): linux-x64 进发布名单，两档 Linux 转 mode=ci，arm64 只构建不发布 
发布流水线默认从 2 个槽位变 4 个：`linux-x64`（ubuntu-22.04）与 `linux-arm64`
（ubuntu-22.04-arm）的 mode 由 probe 改 ci，tag 推送默认就编。

构建 ≠ 发布仍由 `PUBLISH_SLOTS` 决定，本轮只加 `linux-x64`：
- `linux-x64` 有运行时证据 —— release 产物在 Linux 真机（Ubuntu 22.04 + WSLg 真窗口）
  渲出一帧、[theme]/[backend] final 日志齐全、像素判定通过，真窗口 1180x760 从 Windows
  侧截屏可见；`release-build.yml` 另加一条**同槽位**的 xvfb 运行时门禁（只在
  `inputs.slot == 'linux-x64'` 上跑，不给没验过的 arm64 造红）。
- `linux-arm64` 只有构建证据、运行时零证据，产物照出 artifact 取证但不发布；解锁条件
  （真机渲出一帧 + 主题日志）写进 release-notes 与 §9。

守卫跟着扩（`packaging/check_publish_slots.py`）：
- 自测从 8 条扩到 11 条，新增「声明的 linux-x64 构建红了 ⇒ 必须红（挡住发布）」、
  「linux-arm64 有产物但没声明 ⇒ 只警告」、「提前把 linux-arm64 写进名单 ⇒ 缺产物必红」；
- probe 档样例从 linux-x64 换成仍是 probe 的 macos-arm64（否则该用例会从「必须红」
  变成「本来该绿」）；
- 新增「mode=ci 却本次没产物 ⇒ ::warning::」：红一档不能只表现为表里少一行。

文档矩阵同步（release-notes §Downloads/§Support matrix、compliance §9/§10、
artifacts §1、build-and-ci §3、README ×2），两份文档都把 Linux 写成
「已构建并发布（x64）/ 已构建未发布（arm64）」，并把新发现写实：Linux 上整窗透明
与圆角没有代码路径（hwnd=none / corner=policy=system），不是「未验」；Linux 上
`ull update apply` 会拒绝 portable-zip（清单里现在有 linux-x64 产物）。

证据账（含实测输出、CI 增量估算、未验清单）：packaging/docs/linux-evidence.md。
2026-11-08 21:35:26 +08:00

6.1 KiB
Raw Blame History

产物矩阵与版本来源（M145 拆自 packaging/README.md）

本文承载原 packaging/README.md 的 §1、§2，节号沿用原编号（全仓 packaging/README.md §N 这类引用照旧有效， 对照表在 packaging/README.md 的索引里）。内容一字未改、只搬家：本行以上是 M145 新增的导航说明， 以下逐行取自原文件。

1. 产物矩阵

槽位 本版发布 产物文件名 形态 归档内容
windows-x64 ✅ 发布 unlucky-launcher_<ver>_windows_x64.exe 裸 exe（双击即用） exe 单文件；三份合规文本作为并列 Release 资产
linux-x64 ✅ 发布 unlucky-launcher_<ver>_linux_x64.tar.gz 单二进制归档 unlucky-launcher + LICENSE + NOTICE + README.md；CI 在原生 ubuntu-22.04（glibc 2.35 地板）上构建，并有同槽位的 xvfb 运行时门禁（真渲一帧 + [theme] / [backend] final 日志断言 + 像素判定）；真机验收证据见 docs/linux-evidence.md
windows-arm64 ❌ 不发布（构建取证中） unlucky-launcher_<ver>_windows_arm64.exe 裸 exe（同 x64 策略） 同上；CI 在原生 windows-11-arm（Windows 11 Arm64 + VS2026 镜像）上构建，M164 起编译前体检只取证、不再判定红绿（此前五轮全红其实全红在那个误判的体检步），红了不挡发布（M142，见 §3）
linux-arm64 ❌ 已构建、不发布（运行时零证据） unlucky-launcher_<ver>_linux_arm64.tar.gz 单二进制归档（原生 ubuntu-22.04-arm 构建，与 x64 同 glibc 地板） 同上；M184 起默认就编（mode: ci），但没有任何 ARM64 真机跑过一帧 ⇒ 不进 PUBLISH_SLOTS。解锁条件 = 真机渲出一帧 + 主题日志
macos-arm64 ❌ 不构建（未验证） unlucky-launcher_<ver>_macos_arm64.tar.gz 单二进制归档 同上
macos-x64 ❌ 不构建（未验证） unlucky-launcher_<ver>_macos_x64.tar.gz 单二进制归档 同上
每槽位 随所属槽位 ull_<ver>_<平台>_<架构>[.exe] 裸 CLI 文件（独立资产，不进 tar.gz） 零 UI 依赖的 ull 本体，进同一份 SHA256SUMS.txt
全平台 仅已发布资产 SHA256SUMS.txt 校验清单 每行 <sha256>␠␠<文件名>（sha256sum -c 可直吃）
全平台 仅已发布资产 manifest.json 更新清单（D50，见 README.md §13） 渠道 + 版本 + 各平台产物（target/format/url/size/sha256）；生成器 make_manifest.py

约定细节：

  • 「不构建」= CI 默认根本不跑（M139）：macOS 那两档未验证，产物不给用户、构建配额也不花；要整表六槽位取证走 gh workflow run release.yml -f all_slots=true（§3）。发布白名单是 windows-x64 + linux-x64（M184）。 「已构建但不发布」是独立的一档（linux-arm64、windows-arm64）：它们 mode: ci、每轮都编，产物留在 dist-<slot> artifact 里取证，裁剪步会把它们剔出 Release。 （M164/M184）名单 ⇄ 产物两个方向都有守卫 packaging/check_publish_slots.py：声明了缺产物 ⇒ 红；有产物但没声明 ⇒ ::warning:: 明说「未发布、会被裁掉」；mode: ci 却本次没产物 ⇒ 也打 ::warning::（那一档红了要看得见）。
  • 产物命名：<名字>_<版本号>_<平台>_<架构>，下划线分段、不带实现细节字样（不出现 iced）；真相源是 make_artifacts.py::asset_stem()。
  • "单文件"指可执行文件本身零运行时依赖（无 WebView、无 JRE、无 sidecar、无 DLL 旁挂）；归档里的三份合规文本是许可义务、不是运行时依赖，Windows 因为"一个 exe 装不下文本"， 把 LICENSE / NOTICE / README.md 作为 Release 的并列资产分发，条款同样随下载走。
  • 归档解压后是一个顶层目录 unlucky-launcher_<ver>_<平台>_<架构>/，用户不会解压出一堆散文件。
  • ull 是并列的裸资产，不塞进 tar.gz：headless 用户要的就是「下一个小文件直接跑」；归档里放 LICENSE/NOTICE/README.md 是许可义务，而这三份本来就作为并列 Release 资产分发，裸 ull 不缺条款。
  • unlucky-launcher 本体也认全部 CLI 子命令（M82），ull 不是第二个界面，而是不链接图形栈的同一套命令（差异见 §4 与 §7.4），两者不是重复品。 M118：GUI 的构建产物名是 unlucky-launcher-iced（crates/app 已被 workspace exclude，不再产出 unlucky-launcher）；对外文件名仍是 unlucky-launcher，改名在 make_artifacts.py 落盘时（LAUNCHER_BIN 找产物 / LAUNCHER_ASSET 定对外名），所以下载链接 / SHA256SUMS / 本文矩阵不变。
  • <ver> 不带前导 v（tag 是 v0.2.2，文件名是 0.2.2）——由脚本统一裁剪。
  • UNIX 归档内 mtime/uid/gid 归零、权限固定（二进制 0755、文本 0644）， 同源构建的 sha256 不受打包时刻影响。
  • 架构不靠猜：脚本打包前回读二进制的可执行文件头（PE 机器码 / ELF e_machine / Mach-O cputype），与槽位声明的架构不符即失败——不会出现"名字是 arm64、内容还是 x64"的假产物。

2. 版本来源（唯一真相源）

版本号只有一个来源：Cargo.toml 的 [workspace.package] version。

  • <ver> 由 make_artifacts.py 通过 cargo metadata --no-deps 读出（不是正则扒文件）， 任何一个 workspace member 版本不一致时直接失败。
  • 带 tag 构建时（CI）额外传 --version "$TAG"：脚本裁剪 v 后与 Cargo.toml 交叉校验， 不一致即失败——避免出现 tag 说 0.2.2、产物里写 0.2.1 的发布事故。
  • ull --version 必报同一版本（脚本打包前跑一次冒烟 ull --version 断言版本串在其中）， 这是 env!("CARGO_PKG_VERSION") 的实际输出，不是估算。
  • 发布流程：先改 Cargo.toml 版本 + 提交 → git tag v<ver> → 推送 tag 触发流水线。
Reference in new issue View Git Blame Copy Permalink