|
|
40a84a0635
|
ci(release): [skip-release-tests] 标记改查发版提交，不再查 HEAD
原实现用 `git log -1 --pretty=%B`（即 HEAD）找标记。但发版提交之后
往往还会跟几个提交（同步 workflow、改文档、修脚本），HEAD 一移动，
标记就被顶掉 —— 跳过机制**静默失效**，流水线又回去撞旧线的红测试。
改为查**改动 internal/meta/meta.go 的那个提交**（语义上正是「发版提交」）：
REL_COMMIT=$(git log -1 --format=%H -- internal/meta/meta.go)
顺带把 grep -qF 换成 case 匹配，避免多层引号嵌套。
自测（本地 worktree）：
发版提交 472d908 → 命中标记 ✓
HEAD fa5b1b4 → 不命中（旧逻辑会在此静默失效）
actionlint 全绿。
|
2026-09-29 14:03:37 +08:00 |
|
|
|
fa5b1b4840
|
ci(release): 打包前装 Electron，否则 GUI 被静默跳过
## 问题
打包脚本从两处找 Electron 运行时：
1) ~/.cache/electron 里的 electron-v<ver>-linux-<arch>.zip
2) cmd/gui/node_modules/electron/dist（目标架构 == host 时）
全新 GitHub runner **两处都没有** —— 脚本在都没有时只能跳过 GUI，
于是 client/full 包会**静默地不含界面**（正是脚本作者担心的「假包」）。
实测：本地移走缓存后 GUI 被跳过，包仍能产出。
## 改法
打包前在 cmd/gui 执行 `npm ci`，让 electron 落到 node_modules。
runner 是 amd64 == 目标架构，脚本便走第 2 条路径。
**用 npm ci 而不是 `npm install electron@<range>`**：后者是非确定性的
（range 会随上游漂移，也锁不住传递依赖），zizmor 也把它标为
adhoc-packages 风险。package-lock.json（lockfileVersion 3）已锁定
electron，ci 严格按 lock 安装 ⇒ 同一 commit 永远得到同一套依赖。
不能用 `npm install --production`：那会跳过 devDependencies，
而 electron 正是 devDependency（这正是脚本自己那条命令找不到它的原因）。
## 验证
- 无声 cache + 有 node_modules/electron 时，脚本走 host-arch 回退并
成功构建 GUI（263M / x86-64）—— 已本地实测
- 两者都无时改为打印明确原因并跳过（配合上一个 commit 的 find 修复）
- npm ci --dry-run 通过；actionlint 全绿
|
2026-09-29 14:02:34 +08:00 |
|
|
|
64a2238bde
|
ci: 同步 release workflow 到本发布线（go test 门可显式跳过）
|
2026-09-29 13:41:09 +08:00 |
|
|
|
de890aadd6
|
ci: 把 CI 与 Release 流水线带到本条发布线
GitHub 用**被推送 commit 里的** .github/workflows/*.yml 决定是否触发，
所以 workflow 文件必须存在于发布分支本身，否则推 release/** 不会发版。
只带 workflow 定义，不带 main 上的其它未发布改动。
|
2026-09-29 13:21:08 +08:00 |
|
