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
@@ -220,17 +220,24 @@ This list is the reason to believe the rest. None of it is hidden behind marketi
|
||||
section*, *Add override*. Each writes `[page] 占位动作 …` to stderr and changes nothing — instance
|
||||
management from the GUI is the instance-wizard work still outstanding, and settings change as you
|
||||
edit them rather than on a Save.
|
||||
- **Linux and macOS artifacts are unverified, and this release does not even build them.** The
|
||||
reference machine is Windows; the `linux-x64`, `linux-arm64`, `macos-arm64` and `macos-x64` slots
|
||||
sit in the CI matrix but the default release run skips them, and they have never been downloaded and
|
||||
run end to end. `gh workflow run release.yml -f all_slots=true` builds them for evidence. Treat them
|
||||
as untested output, not as "supported because the matrix lists them".
|
||||
- **macOS is not finalised.** It has two rounds of real-device evidence (Apple Silicon), which is why
|
||||
the build exists — but the menu-bar name, the placement of the three window buttons (macOS puts
|
||||
them top-left; ours are drawn top-right), and 300s+ steady state still need a real machine. macOS
|
||||
builds are unsigned, so the first launch needs the Gatekeeper quarantine attribute cleared
|
||||
(`xattr -d com.apple.quarantine`). The macOS runtime smoke job is a manual `workflow_dispatch`
|
||||
probe with `continue-on-error`, not a gate.
|
||||
- **Linux x64 is published, and "published" means "it runs", not "it looks finished".** The release workflow
|
||||
builds `linux-x64` on a native Ubuntu 22.04 runner by default and ships it, because the release artifact itself
|
||||
was started under a real display server (WSLg), opened a window, rendered a non-blank frame and printed its
|
||||
theme/backend lines — and that same check is now a per-slot CI gate on every release
|
||||
(`packaging/docs/linux-evidence.md` has the raw output). Nobody has yet looked at it on a real desktop
|
||||
distribution: dragging, resizing, font metrics and CJK shaping on a real desktop session are unverified.
|
||||
Two things from the Windows list are simply not code paths on Linux, so there is nothing to verify: whole-window
|
||||
transparency needs a native window handle the app does not have there (`hwnd=none`), and rounded corners are
|
||||
delegated to the desktop compositor (`corner=policy=system`) instead of being drawn by the app.
|
||||
`linux-arm64` is built (native `ubuntu-22.04-arm`) but **not** published — no ARM64 machine has ever run it, so
|
||||
the artifact stays as build evidence only.
|
||||
- **macOS is not built by the release workflow, and it is not finalised.** It has two rounds of real-device
|
||||
evidence (Apple Silicon), which is why the build exists at all — but the menu-bar name, the placement of the
|
||||
three window buttons (macOS puts them top-left; ours are drawn top-right), and 300s+ steady state still need a
|
||||
real machine. macOS builds are unsigned, so the first launch needs the Gatekeeper quarantine attribute cleared
|
||||
(`xattr -d com.apple.quarantine`). The macOS runtime smoke job is a manual `workflow_dispatch` probe with
|
||||
`continue-on-error`, not a gate; `gh workflow run release.yml -f all_slots=true` builds the two slots for
|
||||
evidence, but they are never published.
|
||||
- **The content library is cramped at low window heights**, and the window height is not wired into
|
||||
the page model yet — the page lays itself out for a nominal height rather than the one it gets.
|
||||
- **Launch-side failure text is not structured.** The tile takes a Chinese sentence straight from the
|
||||
@@ -253,25 +260,28 @@ Grab the file for your platform from
|
||||
| Slot | Asset | Shape |
|
||||
|------|-------|-------|
|
||||
| `windows-x64` | `unlucky-launcher_<version>_windows_x64.exe` | bare `.exe`, double-click to run |
|
||||
| `windows-arm64` | `unlucky-launcher_<version>_windows_arm64.exe` | bare `.exe` — **not yet published**, see below |
|
||||
| `linux-x64` | `unlucky-launcher_<version>_linux_x64.tar.gz` | one archive, one top-level directory — **not yet published** |
|
||||
| `linux-arm64` | `unlucky-launcher_<version>_linux_arm64.tar.gz` | same — **not yet published** |
|
||||
| `macos-arm64` | `unlucky-launcher_<version>_macos_arm64.tar.gz` | same — **not yet published** |
|
||||
| `macos-x64` | `unlucky-launcher_<version>_macos_x64.tar.gz` | same — **not yet published** |
|
||||
| `linux-x64` | `unlucky-launcher_<version>_linux_x64.tar.gz` | one archive, one top-level directory; glibc 2.35+ and the X11/Wayland + fontconfig stack |
|
||||
| `windows-arm64` | `unlucky-launcher_<version>_windows_arm64.exe` | bare `.exe` — **built, not published**, see below |
|
||||
| `linux-arm64` | `unlucky-launcher_<version>_linux_arm64.tar.gz` | same — **built, not published** (no runtime evidence yet) |
|
||||
| `macos-arm64` | `unlucky-launcher_<version>_macos_arm64.tar.gz` | same — **not built** by the release workflow |
|
||||
| `macos-x64` | `unlucky-launcher_<version>_macos_x64.tar.gz` | same — **not built** by the release workflow |
|
||||
| every published slot | `ull_<version>_<platform>_<arch>[.exe]` | bare CLI binary, its own asset |
|
||||
| all | `SHA256SUMS.txt` | `sha256sum -c` eats it directly |
|
||||
|
||||
**This release publishes `windows-x64` and nothing else.** The publish job keeps only the slots named
|
||||
in `PUBLISH_SLOTS` (`.github/workflows/release-publish.yml`) and deletes every other artifact before
|
||||
it writes `SHA256SUMS.txt`, so a row marked **not yet published** is a naming rule, not a downloadable
|
||||
asset. A guard (`packaging/check_publish_slots.py`) watches both directions: a slot named in the list
|
||||
whose artifacts are missing turns the release red, and artifacts that exist for an unlisted slot get an
|
||||
explicit "not published" warning instead of being deleted quietly. Of those rows `windows-arm64` is the
|
||||
one CI still builds — natively, on GitHub's `windows-11-arm` runner (Windows 11 Arm64 + Visual Studio
|
||||
2026), for evidence. Every ARM64 failure so far came from a pre-build toolchain probe that aborted before
|
||||
`cargo build` ran; that probe is now evidence-only, so an upcoming CI run is the first real answer to
|
||||
whether the slot can produce a binary. Its `.exe` stays out of the release until then; the row stays
|
||||
because the architecture is still supported.
|
||||
**This release publishes `windows-x64` and `linux-x64`, and nothing else.** The publish job keeps only the slots
|
||||
named in `PUBLISH_SLOTS` (`.github/workflows/release-publish.yml`) and deletes every other artifact before it
|
||||
writes `SHA256SUMS.txt`, so a row marked **not published** is a naming rule, not a downloadable asset. A guard
|
||||
(`packaging/check_publish_slots.py`) watches all three relations: a slot named in the list whose artifacts are
|
||||
missing turns the release red (that is also what makes a red `linux-x64` build block the release), artifacts that
|
||||
exist for an unlisted slot get an explicit "not published" warning instead of being deleted quietly, and a
|
||||
`mode: ci` slot that produced nothing at all warns too — a red slot must never be visible only as a missing row.
|
||||
|
||||
Of the unlisted rows, CI builds two. `windows-arm64` is built natively on GitHub's `windows-11-arm` runner
|
||||
(Windows 11 Arm64 + Visual Studio 2026); every ARM64 failure so far came from a pre-build toolchain probe that
|
||||
aborted before `cargo build` ran, that probe is now evidence-only, and the next CI run is the first real answer to
|
||||
whether the slot can produce a binary. `linux-arm64` is built natively on `ubuntu-22.04-arm` (same glibc 2.35 floor
|
||||
as x64) and is unpublished for a different reason: **nothing has ever run it on ARM64 hardware**. One frame plus the
|
||||
theme/backend log lines on a real ARM64 machine is the unlock condition; until then the artifact is build evidence.
|
||||
|
||||
Each UNIX archive contains the executable plus `LICENSE`, `NOTICE` and `README.md`, in one top-level
|
||||
directory. Windows ships a bare `.exe` (a single file cannot carry the texts), so those three
|
||||
@@ -279,6 +289,18 @@ documents are attached to the release next to it — downloading the Windows bin
|
||||
licence. Download links never carry implementation detail in the name, and the binary inside an
|
||||
archive is always called `unlucky-launcher`.
|
||||
|
||||
On Linux x64 that is the whole install:
|
||||
|
||||
```bash
|
||||
tar -xzf unlucky-launcher_<version>_linux_x64.tar.gz
|
||||
cd unlucky-launcher_<version>_linux_x64
|
||||
./unlucky-launcher # add --software-renderer if there is no usable GPU adapter
|
||||
```
|
||||
|
||||
It asks for glibc 2.35+ (the slot is built on Ubuntu 22.04), `libxkbcommon`, `fontconfig` and `libGL`; on
|
||||
Debian/Ubuntu `sudo apt-get install libxkbcommon0 libfontconfig1 libgl1 libx11-6 libxcursor1 libxrandr2 libxi6`
|
||||
covers the load-time set, and the bare `ull_<version>_linux_x64` beside the archive needs no display at all.
|
||||
|
||||
The two shapes are not duplicates. The GUI binary needs the graphics stack when it opens a window (it
|
||||
`dlopen`s X11 / Wayland / GL and links `libfontconfig` at load); `ull` needs nothing beyond glibc, so
|
||||
it runs on a server or a CI container where no window can exist. On Linux that floor is glibc ≥ 2.35
|
||||
@@ -345,7 +367,7 @@ merge. The macOS probe is not there yet — manual dispatch only, result recorde
|
||||
|----------|---------|
|
||||
| `.github/workflows/ci.yml` | fmt + clippy + test + release build (Windows / Linux matrix); Linux runtime smoke (Xvfb, one real frame, PNG asserted non-blank); macOS runtime probe (manual dispatch only) |
|
||||
| `.github/workflows/guards.yml` | zero-UI guards (`crates/core`, `crates/presenter`, `crates/design`), 400-lines-per-file guard, cargo-deny licence and source guard |
|
||||
| `.github/workflows/release.yml` | tag `v*` → build both Windows slots (`windows-x64` + `windows-arm64`) on native runners → single-file artifacts + `SHA256SUMS.txt` → GitHub Release (publishes `windows-x64` only; `-f all_slots=true` builds all six slots for evidence) |
|
||||
| `.github/workflows/release.yml` | tag `v*` → build the four default slots (`windows-x64` + `windows-arm64` + `linux-x64` + `linux-arm64`) on native runners → single-file artifacts + `SHA256SUMS.txt` → GitHub Release (publishes `windows-x64` and `linux-x64`; `linux-x64` also gets a per-slot Xvfb first-frame gate; `-f all_slots=true` builds all six slots for evidence) |
|
||||
| `.github/workflows/release-guard.yml` | release-marker semantics: push tag ⇒ a **stable** release, dispatch `prerelease=true` ⇒ pre-release; the table lives in `packaging/release_marker.py` and the guard mutation-tests itself |
|
||||
|
||||
## Architecture and module map
|
||||
|
||||
Reference in new issue
Block a user