jkooe
9f95560268
## 问题
`scripts/release.mjs` 只产出 agent / cli / mcp，`apps/console` 从来没接进去。
后果很具体：今天修的 6 个真机缺陷（转圈、状态卡死、退出确认、复用、断管、ws/wss）
**只存在于 CI artifact**，而 artifact retention 是 7 天。
用户从 Release 页面下载到的，永远是旧控制台。
## 做法
1. `console-windows.yml` 加 `workflow_call:`，并新增 `publish` job：
- `if: startsWith(github.ref, 'refs/tags/v')` —— 只有 tag 才发布，日常分支构建跳过
- 下载两架构产物 → 断言安装包数 ≥ 4（exe+msi × x64/arm64），少了直接报红，
**绝不静默少发一个架构**
- `gh release upload --clobber` 挂到 `release.mjs` 建好的那个 Release
- release.mjs 在本地跑、与本工作流并行，故先轮询等 Release 出现（最多 10 分钟）；
等不到就给 `::warning::` 并跳过，不阻塞流水线
2. 新增 `console-release.yml`：只认 `push: tags: ['v*']`，`uses:` 调用上面那个工作流
## 为什么不直接把 tags 写进 console-windows.yml
它带 `paths` 过滤。`paths` 与 `tags` 并存时，tag 推送会被路径判定挡掉而**静默不触发** ——
失败形态是「什么都没发生」，最难察觉。拆成「日常验证走分支 + 发布只认 tag」最稳。
验证：PyYAML 解析通过；triggers / jobs 结构正确；shell 转义已核对。
（tag 发布路径需真打一次 tag 才能端到端验证，见下文待办）
29 lines
922 B
YAML
29 lines
922 B
YAML
name: Console Release
|
|
|
|
# 控制台发布工作流（tag 触发）。
|
|
#
|
|
# 为什么不把 `tags` 直接写进 console-windows.yml 的 push 里
|
|
# ------------------------------------------------
|
|
# 那个工作流带 `paths` 过滤。`paths` 与 `tags` 同时出现时，tag 推送会被
|
|
# 路径判定挡掉而**静默不触发** —— 这是 GitHub Actions 的经典坑，
|
|
# 且失败形态是「什么都没发生」，最难察觉。
|
|
# 故拆成：日常验证走 console-windows（分支 + paths），发布走本工作流（只认 tag）。
|
|
#
|
|
# 交付物去向：本工作流构建两台架构的安装包，再由 console-windows 里的
|
|
# `publish` job 补挂到 `scripts/release.mjs` 创建的那个 Release 上。
|
|
|
|
on:
|
|
push:
|
|
tags:
|
|
- 'v*'
|
|
|
|
# 发布需要写 Release
|
|
permissions:
|
|
contents: write
|
|
|
|
jobs:
|
|
console:
|
|
uses: ./.github/workflows/console-windows.yml
|
|
permissions:
|
|
contents: write
|