24 lines
1.7 KiB
Markdown
24 lines
1.7 KiB
Markdown
---
|
||
name: factory-release
|
||
description: Use when the user explicitly asks to release the factory backend, run its release workflow, or bump its deployed version.
|
||
---
|
||
|
||
# 发布 Factory 后端
|
||
|
||
仅在用户明确要求后端发版、release 或提升部署版本时执行本流程。普通代码修改、提交或推送不触发发版。
|
||
|
||
严格按以下顺序执行：
|
||
|
||
1. 确认目标是当前 `factory` 后端。若用户要求发布 `ehs_web` 前端，改读 `.codex/memory/reference_ehs_web_release.md`。
|
||
2. 执行 `git status --short`，确认工作区状态。发布提交只能包含 `changelog.md` 和 `server/settings.py`；不得混入其他已修改或未跟踪文件。
|
||
3. 执行 `bash update_changelog.sh`，从脚本输出读取形如 `3.1.YYYYMMDDHH` 的版本号，记为 `<VER>`。不得自行编造或改写版本号。
|
||
4. 把 `server/settings.py` 中唯一权威版本字段 `SYS_VERSION` 更新为 `<VER>`。
|
||
5. 读取 `changelog.md` 顶部约 20 行，确认标题是 `## <VER>`，且自上一个 tag 起的提交分类合理。出现重复段、明显漏项或无关内容时，先向用户确认，不得继续打 tag。
|
||
6. 再次检查 diff，只暂存 `changelog.md` 和 `server/settings.py`。
|
||
7. 提交信息使用 `release: <VER>`，不添加工具或模型专属署名。
|
||
8. 创建无 `v` 前缀的 tag：`git tag <VER>`。
|
||
9. 推送当前分支到 `origin`，成功后再执行 `git push origin <VER>`。逐步检查结果，不用命令链掩盖中间失败。
|
||
10. 汇报 `<VER>`、changelog 包含的提交类别、commit hash、tag 名，以及分支和 tag 的推送结果。
|
||
|
||
若提交、tag 或推送中途失败，先检查实际 Git 状态。任何会重写历史或删除远端 tag 的回退操作，都必须先取得用户明确授权。
|