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。
This commit is contained in:
AskaEth committed
1 parent
dc3fa2be87
commit
2813e2984c
14 files changed
+608
-151
No files matched your search
+40
-21
@@ -175,14 +175,18 @@ unlucky-launcher --version # CLI，版本 + 系统摘要
|
||||
- **有一批按钮是占位。** 实例页：*新建实例*、*导入*、*复制*、*打开文件夹*、*删除*。日志页：*打开文件夹*。
|
||||
设置页框架：*保存*、*重置本组*、*添加覆盖*。点下去只往 stderr 写一行 `[page] 占位动作 …`，什么都不改
|
||||
——图形界面里的实例管理就是还欠着的那块实例向导；设置项是边改边生效，而不是靠「保存」。
|
||||
- **Linux 与 macOS 产物未验证，而且本版连构建都不跑。** 参考机是 Windows；`linux-x64`、`linux-arm64`、
|
||||
`macos-arm64`、`macos-x64` 四档只躺在 CI 矩阵里，默认的发布流程会跳过它们，也还没被下载下来端到端跑过；
|
||||
`gh workflow run release.yml -f all_slots=true` 才编它们来取证。把它们当**未经测试的产出**，而不是
|
||||
「矩阵里有就算支持」。
|
||||
- **macOS 未定型。** 有两轮真机证据（Apple Silicon），构建因此存在——但菜单栏显示名、三个窗口按钮的位置
|
||||
（macOS 习惯在左上，我们自绘在右上）、300s+ 稳态仍需真机复核。macOS 产物未签名，首次启动要自己清掉
|
||||
Gatekeeper 隔离标记（`xattr -d com.apple.quarantine`）。macOS 运行期冒烟是手动 `workflow_dispatch`
|
||||
的探针、带 `continue-on-error`，不是门禁。
|
||||
- **Linux x64 已发布，但「已发布」= 真能跑，不等于观感已定型。** 发布流水线默认就在原生 Ubuntu 22.04 上编
|
||||
`linux-x64` 并发出去，依据是：release 产物本身在真显示服务（WSLg）下起过窗、渲出一帧非空白画面、主题与渲染
|
||||
后端的日志行齐全（实测输出见 `packaging/docs/linux-evidence.md`），而且同一条判据已经常驻成发布流水线里
|
||||
**这个槽位**的门禁。还没人看过的：真实桌面发行版上的拖动/缩放，以及真桌面会话里的字体度量与中文整形。
|
||||
「整窗透明度」与「圆角」这两条在 Linux 上**根本没有代码路径**（不是未验）：前者要窗口句柄，Linux 上拿不到
|
||||
（`hwnd=none`）；后者交给桌面合成器（`corner=policy=system`），我们不自己画。
|
||||
`linux-arm64` 只是**编出来了，没发布**——没有任何 ARM64 机器跑过它一帧，产物只作构建证据留着。
|
||||
- **macOS 不由发布流水线构建，也未定型。** 有两轮真机证据（Apple Silicon），构建因此存在——但菜单栏显示名、
|
||||
三个窗口按钮的位置（macOS 习惯在左上，我们自绘在右上）、300s+ 稳态仍需真机复核。macOS 产物未签名，
|
||||
首次启动要自己清掉 Gatekeeper 隔离标记（`xattr -d com.apple.quarantine`）。macOS 运行期冒烟是手动
|
||||
`workflow_dispatch` 的探针、带 `continue-on-error`，不是门禁；`gh workflow run release.yml -f all_slots=true`
|
||||
能编这两档取证，但它们从不发布。
|
||||
- **内容库页在低窗口高度下会挤**，而且窗口高度还没接进页面模型——这一页按一个名义高度排版，而不是按它
|
||||
真正拿到的高度。
|
||||
- **启动侧失败提示未结构化。** 磁贴直接采用启动层抛出的中文句子
|
||||
@@ -202,22 +206,37 @@ unlucky-launcher --version # CLI，版本 + 系统摘要
|
||||
| 槽位 | 产物 | 形态 |
|
||||
|------|------|------|
|
||||
| `windows-x64` | `unlucky-launcher_<版本>_windows_x64.exe` | 裸 `.exe`，双击即用 |
|
||||
| `windows-arm64` | `unlucky-launcher_<版本>_windows_arm64.exe` | 裸 `.exe` —— **暂未发布**，见下 |
|
||||
| `linux-x64` | `unlucky-launcher_<版本>_linux_x64.tar.gz` | 单个归档，解压出一个顶层目录 —— **暂未发布** |
|
||||
| `linux-arm64` | `unlucky-launcher_<版本>_linux_arm64.tar.gz` | 同上 —— **暂未发布** |
|
||||
| `macos-arm64` | `unlucky-launcher_<版本>_macos_arm64.tar.gz` | 同上 —— **暂未发布** |
|
||||
| `macos-x64` | `unlucky-launcher_<版本>_macos_x64.tar.gz` | 同上 —— **暂未发布** |
|
||||
| `linux-x64` | `unlucky-launcher_<版本>_linux_x64.tar.gz` | 单个归档，解压出一个顶层目录；要 glibc 2.35+ 与 X11/Wayland + fontconfig 那一套 |
|
||||
| `windows-arm64` | `unlucky-launcher_<版本>_windows_arm64.exe` | 裸 `.exe` —— **编了、不发布**，见下 |
|
||||
| `linux-arm64` | `unlucky-launcher_<版本>_linux_arm64.tar.gz` | 同上 —— **编了、不发布**（运行时零证据） |
|
||||
| `macos-arm64` | `unlucky-launcher_<版本>_macos_arm64.tar.gz` | 同上 —— 发布流水线**不构建** |
|
||||
| `macos-x64` | `unlucky-launcher_<版本>_macos_x64.tar.gz` | 同上 —— 发布流水线**不构建** |
|
||||
| 每个已发布槽位 | `ull_<版本>_<平台>_<架构>[.exe]` | 裸 CLI 文件，独立资产 |
|
||||
| 全平台 | `SHA256SUMS.txt` | `sha256sum -c` 可直吃 |
|
||||
|
||||
**本版只发布 `windows-x64`。** 发布 job 只留 `PUBLISH_SLOTS` 里点名的槽位
|
||||
**本版发布 `windows-x64` 与 `linux-x64`，就这两档。** 发布 job 只留 `PUBLISH_SLOTS` 里点名的槽位
|
||||
（`.github/workflows/release-publish.yml`），其余产物在写 `SHA256SUMS.txt` 之前就被删掉——所以表里标
|
||||
**暂未发布** 的行是命名规则，不是本版可下载的资产。两个方向都有守卫（`packaging/check_publish_slots.py`）：
|
||||
名单里点名了却没产物 ⇒ Release 变红；产物在、名单没点名 ⇒ 显式打「未发布」警告，不再静默删掉。
|
||||
这几行里 `windows-arm64` 是 CI 唯一真跑的那档：在 GitHub 原生 `windows-11-arm`（Windows 11 Arm64 +
|
||||
Visual Studio 2026）runner 上编来取证。**诚实一句**：此前每一次 arm64 红都红在**编译前的工具链体检**，
|
||||
`cargo build` 一次都没跑过；M164 把那个体检降级成只取证，所以**下一条 tag 的 CI 才是第一次真正问编译器**。
|
||||
在那之前它的 `.exe` 不进 Release；行不删是因为架构仍要支持，真出包了就把键加回 `PUBLISH_SLOTS`（一行）。
|
||||
**不发布** 的行是命名规则，不是本版可下载的资产。三条关系都有守卫（`packaging/check_publish_slots.py`）：
|
||||
名单里点名了却没产物 ⇒ Release 变红（`linux-x64` 构建红了就挡住整次发布，靠的就是这条）；产物在、名单没点名
|
||||
⇒ 显式打「未发布」警告，不再静默删掉；`mode: ci` 的槽位本次连产物都没有（那一档红了）⇒ 也打警告。
|
||||
|
||||
不发布的行里 CI 真编两档。`windows-arm64` 在 GitHub 原生 `windows-11-arm`（Windows 11 Arm64 + Visual Studio
|
||||
2026）上编来取证——**诚实一句**：此前每一次 arm64 红都红在**编译前的工具链体检**，`cargo build` 一次都没跑过；
|
||||
M164 把那个体检降级成只取证，所以**下一条 tag 的 CI 才是第一次真正问编译器**。`linux-arm64` 在原生
|
||||
`ubuntu-22.04-arm`（与 x64 同 glibc 地板）上编，不发布的理由完全不同：**没有任何 ARM64 机器跑过它**。
|
||||
解锁条件 = 真机渲出一帧 + 主题/后端日志行，之后才把键加进 `PUBLISH_SLOTS`。
|
||||
|
||||
Linux x64 的安装就是解开归档直接跑：
|
||||
|
||||
```bash
|
||||
tar -xzf unlucky-launcher_<版本>_linux_x64.tar.gz
|
||||
cd unlucky-launcher_<版本>_linux_x64
|
||||
./unlucky-launcher # 没有可用 GPU 适配器就加 --software-renderer
|
||||
```
|
||||
|
||||
载入期要 glibc 2.35+、`libxkbcommon`、`fontconfig`、`libGL`；Debian/Ubuntu 上
|
||||
`sudo apt-get install libxkbcommon0 libfontconfig1 libgl1 libx11-6 libxcursor1 libxrandr2 libxi6` 就够。
|
||||
与归档并列的裸 `ull_<版本>_linux_x64` 连显示都不需要。
|
||||
|
||||
UNIX 归档里是二进制加 `LICENSE`、`NOTICE`、`README.md`，都在一个顶层目录下。Windows 发的是裸 `.exe`
|
||||
（一个文件装不下这三份文本），所以这三份作为并列资产挂在 Release 上——下 Windows 二进制不会把许可条款
|
||||
@@ -278,7 +297,7 @@ cargo deny check licenses bans sources # 依赖许可（CI 必
|
||||
|----------|------|
|
||||
| `.github/workflows/ci.yml` | fmt + clippy + test + release build（Windows / Linux 矩阵）；Linux runtime smoke（Xvfb 真渲染一帧、断言 PNG 非空白）；macOS 运行期探针（仅手动 dispatch） |
|
||||
| `.github/workflows/guards.yml` | `crates/core` / `crates/presenter` / `crates/design` 零 UI 守门、单文件 ≤400 行守门、cargo-deny 许可与来源守门 |
|
||||
| `.github/workflows/release.yml` | tag `v*` → 构建两个 Windows 槽位（`windows-x64` + `windows-arm64`，各自原生 runner）→ 单文件产物 + `SHA256SUMS.txt` → GitHub Release（只发布 `windows-x64`；`-f all_slots=true` 才整表六槽位取证） |
|
||||
| `.github/workflows/release.yml` | tag `v*` → 构建默认四档（`windows-x64` + `windows-arm64` + `linux-x64` + `linux-arm64`，各自原生 runner）→ 单文件产物 + `SHA256SUMS.txt` → GitHub Release（发布 `windows-x64` 与 `linux-x64`；`linux-x64` 另有一条同槽位的 Xvfb 首帧门禁；`-f all_slots=true` 才整表六槽位取证） |
|
||||
| `.github/workflows/release-guard.yml` | 发布标记语义守门：push tag ⇒ **稳定版**、dispatch `prerelease=true` ⇒ 预发布；标记表在 `packaging/release_marker.py`，守门会对自己做变异自测 |
|
||||
|
||||
## 架构与模块地图
|
||||
|
||||
Reference in new issue
Block a user