diff --git a/.github/workflows/release-guard.yml b/.github/workflows/release-guard.yml index 5669e01..af4f464 100644 --- a/.github/workflows/release-guard.yml +++ b/.github/workflows/release-guard.yml @@ -1,5 +1,12 @@ name: Release guard +# (M268)显式 `run-name`:本文件**不是**可复用工作流(`on:` 是 push main / pull_request / workflow_dispatch), +# 每次都在 Actions 列表里单独占一行,所以同样吃「运行名 = 提交信息」这条默认行为——v0.2.4 的发布提交推到 main 时, +# 那段「孤儿提交 / 无父 / 树 = dev …」在这里也会再泄漏一次。PR 事件的 `github.ref_name` 是 `/merge`, +# 贴出来不人读,故按事件分两支:PR 用 `github.event.pull_request.number`(`github` 上下文,run-name 可用且必有值), +# 其余(push main / dispatch)用 `ref_name`(`refs/heads/main` ⇒ `main`,非空)。**`name:` 一字未动。** +run-name: "${{ github.event_name == 'pull_request' && format('Release guard · PR #{0}', github.event.pull_request.number) || format('Release guard · {0}', github.ref_name) }}" + # 发布标记语义守门(M163):**push tag 默认创建稳定版**这条不许只靠注释保证。 # # 判据全部在 `packaging/check_release_semantics.py`,它做四件事: diff --git a/.github/workflows/release-publish.yml b/.github/workflows/release-publish.yml index 7585c2f..5140185 100644 --- a/.github/workflows/release-publish.yml +++ b/.github/workflows/release-publish.yml @@ -1,5 +1,10 @@ name: Release / publish(可复用) +# (M268)**故意不加 `run-name`**:本文件只有 `on.workflow_call`,由 `release.yml` 的 `release` job `uses:` 调用。 +# 可复用工作流**不产生自己的 run**——它的 job 挂在调用方那一次 run 里(Actions 列表里只有 `release.yml` 那一行, +# 运行名由 `release.yml` 的 `run-name` 决定),所以这里写 run-name 是死代码,写了也不会显示。同理没有 `name:` +# 改动。真正需要 run-name 的另一处是 `release-guard.yml`(那是独立触发的,会单独占一行)。 +# # Release 流水线的**发布侧**(M145 拆分:`release.yml` 顶到 400 行红线)。本文件 = 拆分前 `release.yml` 的 `release` # job **逐字搬家**:裁剪白名单外的槽位产物、重算全量 `SHA256SUMS.txt`、渲染 `packaging/release-notes.md` 模板、 # `gh release create/edit` 的同 tag 幂等,全部照旧。留在调用方 `release.yml` 的只有三件事:`needs: build`、 diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index 03ceff7..fab8d2c 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -1,5 +1,16 @@ name: Release +# (M268)显式 `run-name`:**不写这一行,GitHub 就把提交信息当运行名**贴到 Actions 列表上——公开界面曾经出现 +# 「release: v0.2.4 里程碑快照(孤儿提交,无父;树 = dev 68362e5)」,把 D41 快照模型的实现术语泄漏给所有人。 +# 取值面已核(文档:`run-name` 可用 `github` / `inputs` / `vars`,无特殊函数限制): +# push tag `v0.2.4` ⇒ `github.ref = refs/tags/v0.2.4` / `ref_type = tag` ⇒ `Release v0.2.4` +# dispatch 在 tag ref 上 ⇒ 同上(`gh workflow run release.yml --ref v0.2.4`)⇒ `Release v0.2.4` +# dispatch 在分支 ref 上 ⇒ `github.ref_name = main` / `ref_type = branch` ⇒ `Release 试跑 main(分支 ref,不发布)` +# 两种 ref 面上 `ref_name` 都非空(`ref` 一定存在),故不需要兜底分支。分支 ref 单独成一种写法是因为它被 +# `release` job 的 `if: github.ref_type == 'tag'` 挡在发布之外——一律写 `Release main` 会让人以为 main 上发了版。 +# **只新增 run-name,`name:`(工作流标识符)一字未动**:改名会断掉历史 run 与分支保护/规则的匹配。 +run-name: "${{ github.ref_type == 'tag' && format('Release {0}', github.ref_name) || format('Release 试跑 {0}(分支 ref,不发布)', github.ref_name) }}" + # 发布流水线:tag `v*` → **默认构建四个槽位**(原生 `windows-latest` / `windows-11-arm` / `ubuntu-22.04` / # `ubuntu-22.04-arm`)→ 单文件产物 + SHA256SUMS → artifact + GitHub Release。**push tag 默认创建稳定版**(M163:不带 # `--prerelease`,否则 `releases/latest` 永远 404、自更新通道取不到清单);同 tag 重跑幂等(覆盖资产与说明、不 create、 diff --git a/packaging/README.md b/packaging/README.md index 9bbab58..a4c3314 100644 --- a/packaging/README.md +++ b/packaging/README.md @@ -13,7 +13,7 @@ | 节 | 主题 | 承载文件 | |----|------|---------| | §1 | 产物矩阵 | `packaging/docs/artifacts-and-version.md` | -| §2 | 版本来源(唯一真相源) | `packaging/docs/artifacts-and-version.md` | +| §2 | 版本来源(唯一真相源);§2.1 里程碑快照**提交信息**怎么写(M268) | `packaging/docs/artifacts-and-version.md` | | §3 | 怎么构建(本地 / CI) | `packaging/docs/build-and-ci.md` | | §4 | 每平台运行时依赖 | `packaging/docs/runtime-deps.md` | | §5 | 软渲染兜底 | `packaging/docs/runtime-deps.md` | diff --git a/packaging/docs/artifacts-and-version.md b/packaging/docs/artifacts-and-version.md index 5ed1abb..51804f4 100644 --- a/packaging/docs/artifacts-and-version.md +++ b/packaging/docs/artifacts-and-version.md @@ -51,3 +51,50 @@ - `ull --version` 必报同一版本(脚本打包前跑一次冒烟 `ull --version` 断言版本串在其中), 这是 `env!("CARGO_PKG_VERSION")` 的实际输出,不是估算。 - 发布流程:先改 `Cargo.toml` 版本 + 提交 → `git tag v` → 推送 tag 触发流水线。 + +### 2.1 里程碑快照的提交信息该长什么样(M268) + +发布提交的信息**会出现在公开界面上**(commit 列表、PR、`git log`,以及——没有 `run-name` 时——Actions 的运行名), +所以它是对外文案,不是内部工作记录。 + +默认行为(GitHub 文档原文):`run-name` 省略或只有空白时,运行名取「事件相关的信息」,push / pull_request 触发的 +run 就是**提交信息原文**(PR 则是 PR 标题)。M268 之前 `.github/workflows/` 里 `run-name` 零命中,于是 v0.2.4 那一条的 +标题直接是提交信息:「release: v0.2.4 里程碑快照(孤儿提交,无父;树 = dev 68362e5)」——D41 快照模型的实现术语 +(无父提交、树取自 dev)泄漏到了任何人点开仓库就能看到的地方。v0.2.1~v0.2.3 那几条看着正常,只是因为那几次的 +提交信息本身干净,不是因为流水线做了什么。 + +现在的兜底:`release.yml` 与 `release-guard.yml` 都加了显式 `run-name`(`Release v0.2.4` / `Release guard · main`), +发布相关的 run 名不再由提交信息决定。`release-publish.yml` / `release-build.yml` 是 `workflow_call` 可复用工作流, +**不产生自己的 run**,所以那里不加(理由写在该文件头部注释里)。**但提交信息本身照样公开可见,规矩照旧要守。** + +规矩只有两条: + +1. **版本 + 一句话**,例如 `release: v0.2.4`。想交代一句就写对外的话: + `release: v0.2.4(首个带 Linux 产物的稳定版)`。 +2. **不许写实现细节**:「孤儿提交」「无父」「树 = dev 」「squash 了哪几个提交」这类快照模型的内部术语一个都不要。 + 过程写进 `DevDocs/` 或 PR 描述,不写提交信息。 + +正面例子(就这样写): + +```text +release: v0.2.4 +``` + +反面例子(真实发生过,就是泄漏到 Actions 列表的那一条): + +```text +release: v0.2.4 里程碑快照(孤儿提交,无父;树 = dev 68362e5) +``` + +问题不在长度,在于这段话讲的是**我们怎么做的快照**(无父提交、树取自 dev 68362e5),跟用户无关,还暴露了内部模型。 + +**抓得住什么 / 抓不住什么**: + +- 抓得住(只有这两条):加了 `run-name` 的两个工作流——`Release`(= `release.yml`)与 `Release guard`——的运行名不再 + 由提交信息决定,Actions 列表里固定是 `Release v0.2.4` / `Release guard · main` 这类人读名字。下次谁把提交信息写成 + 内部术语,**这两行不会显示它**。(已发生的那条 v0.2.4 不会追溯改名:历史 run 名是快照。) +- 抓不住(一半):**同一份提交信息在别的 run 上照样公开**。`ci.yml` / `guards.yml` / `dev-guards.yml` / + `gpu-evidence.yml` / `signing-status.yml` 都还是默认行为(没加 `run-name`),所以发布提交推进 `main` 时,那几行仍以 + 提交信息为名。要么给它们也加 `run-name`,要么就别在提交信息里写内部术语——**目前是后者**。 +- 抓不住(另一半):**提交信息本身**。`git log` / commit 页面 / PR 里那段字照旧公开,`run-name` 管不到;这一层只有本节 + + review 时人看一眼。没有任何门禁会因此变红——写一个能判「这段话是不是内部术语」的脚本不现实,别指望它存在。