wangjia
aa7099ba94
将单一 CI/CD 流水线拆成三条互不影响的发布流水线，各有 tag 前缀、独立版本
序列与独立 CHANGELOG：
- client（client-v*）：Flutter 全平台 + version.yaml 自更新清单
- site（site-v*）：web/ Eleventy 营销站，不含 web 版 app
- server（server-v*）：backend Go 服务 + 共享基建 nginx/systemd
新增 3 个 workflow（deploy-client/site/server.yml）替换 deploy.yml；CI 脚本
按 part 拆分为 compile-/release-/deploy-{client,site,server}.sh，抽出公共函数
lib-forgejo.sh；compile-{macos,android,ios,windows}.sh 改去 client-v 前缀；
manual.yml 按前缀路由回滚。
跨流水线解耦：version.yaml 归 client，后端每请求实时读取（不重启、不触发
server 流水线）；官网下载页的版本徽章/下载链接/更新日志时间线运行时经
/api/v1/public/release 动态拉取（API 不可达回退构建时静态内容）。为此一次性
扩展后端 changelog 字段（version.go/public.go）与 download.njk 动态渲染。
CHANGELOG.md 重命名为 CHANGELOG-client.md，新增 CHANGELOG-site/server.md；
重写 /release 命令为 /release <part> [version]；同步更新 CLAUDE.md 与部署文档。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3.4 KiB
3.4 KiB
description, argument-hint, model, allowed-tools
| description | argument-hint | model | allowed-tools |
|---|---|---|---|
| 执行某一条流水线的本地发版（part ∈ client|site|server） | <part> [version] 如 `client 1.0.55` 或 `server` | claude-sonnet-4-6 | Bash, Read, Edit, Write |
执行三条独立流水线之一的本地发版流程。$ARGUMENTS 形如 <part> [version]：
- part（必填）：
client|site|server，分别对应 tag 前缀client-v*/site-v*/server-v*、CHANGELOG 文件CHANGELOG-client.md/CHANGELOG-site.md/CHANGELOG-server.md。 - version（选填）：如
1.0.55。
三者互不影响：client 发版只动 app 产物与 version.yaml（官网下载页与后端 /version 自动同步，无需重建官网/重启后端）；site 只重建营销站；server 只换后端二进制 + nginx。
0. 解析参数
- 校验 part 合法（client|site|server），非法立即报错退出。
- 记 PART = part。
确定版本号 VERSION：
- 给了 version：直接用。
- 没给：
git describe --tags --match "<PART>-v*" --abbrev=0取该前缀最新 tag（如client-v1.0.54），去掉<PART>-v前缀后 patch +1（如1.0.55）。若该前缀尚无任何 tag，则 VERSION=1.0.0。将自动确定的版本号告知用户。 - 记 TAG =
<PART>-v<VERSION>，CHANGELOG_FILE =CHANGELOG-<PART>.md。
按以下步骤顺序执行，任意步骤失败立即停止并报告错误。
1. 检查工作区
检查是否有未提交的改动（git status）。如果有，列出文件并询问用户是否继续。
2. 本地构建 + 测试门禁（按 part）
export PATH="/opt/homebrew/bin:$PATH"
- server：
cd backend && go build ./... && go vet ./... && go test ./... - client：
cd client && flutter analyze --no-fatal-infos --no-fatal-warnings - site：
cd web && npm ci && npm run build
3. 更新 CHANGELOG_FILE
检查 CHANGELOG_FILE 中是否已有 ## [VERSION] 版本节。
- 已有：直接使用，不修改。
- 没有：读取该 part 上一个 tag（
<PART>-v*）到 HEAD 的git log，自动生成版本节插入文件顶部（位于已有版本节之前），格式：
## [VERSION] - <今天日期>
### 新功能
- ...
### 改进
- ...
### 修复
- ...
只保留有内容的分类，按 commit 类型（feat/fix/refactor 等）归类。
CHANGELOG 撰写原则：
- 站在用户视角总结，描述对使用体验的实际影响，而非技术实现。
- 忽略产品感知弱的提交：发版/CI/部署（chore: release、ci:、devops:）、内部文档/规范（docs(claude):、docs(internal):）、纯格式/重构（style:、refactor:）、依赖升级（chore: bump）。
- 保留并重点描述 feat / fix / perf，以及用户可感知的 refactor（界面改版、交互优化）。
- 每条一句话说清"用户能做什么"或"修了什么问题"。
- 范围按 part 过滤：client 只收
client/相关；server 只收backend/相关；site 只收web/（营销站）相关。
4. 提交代码
将所有改动（含 CHANGELOG_FILE）提交到 main：
chore: release <PART>-v<VERSION>
5. 打 tag
git tag <PART>-v<VERSION>
6. 推送
git push ssh://git@git.51yanmei.com:2222/wangjia/jiu.git main <PART>-v<VERSION>
推送成功后提示用户：对应流水线（deploy-）已触发，等待 Telegram 通知。