wangjia
21a4a8cab7
- checks.yml 加 flutter test（DoD 写了但此前无闸，golden 回归全靠自觉； 本地 /release client 门禁同步加了 flutter test，该文件 gitignore 不入库） - check-l1-sync ⑤：backend 公开页模板内联 token 值须与原型 tokens.css 对应主题块一致（模板自包含手拷值，此前仅注释约定零校验；已注入漂移自证） - check-l1-sync ⑥：BADGE_ICON ↔ kStatusIcons 状态词同集（此前两端手工转录） - 顺修 gen_tokens 旧路径注释（client/lib/core/theme/tool/ → client/tool/） Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JJ1g8XV1YhhmHRzhwWEW7o
100 lines
3.4 KiB
Markdown
100 lines
3.4 KiB
Markdown
---
|
||
description: 执行某一条流水线的本地发版（part ∈ client|site|server）
|
||
argument-hint: <part> [version] 如 `client 1.0.55` 或 `server`
|
||
model: claude-sonnet-4-6
|
||
allowed-tools: 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）
|
||
|
||
```bash
|
||
export PATH="/opt/homebrew/bin:$PATH"
|
||
```
|
||
|
||
- **server**：
|
||
```bash
|
||
cd backend && go build ./... && go vet ./... && go test ./...
|
||
```
|
||
- **client**：
|
||
```bash
|
||
cd client && flutter analyze --no-fatal-infos --no-fatal-warnings && flutter test
|
||
```
|
||
- **site**：
|
||
```bash
|
||
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
|
||
|
||
```bash
|
||
git tag <PART>-v<VERSION>
|
||
```
|
||
|
||
## 6. 推送
|
||
|
||
```bash
|
||
git push ssh://git@git.51yanmei.com:2222/wangjia/jiu.git main <PART>-v<VERSION>
|
||
```
|
||
|
||
推送成功后提示用户：对应流水线（deploy-<PART>）已触发，等待 Telegram 通知。
|