[RFC] CI 改进｜根据 PR Label 推送版本

[EstrellaXD]

背景 or 问题

目前使用的 CI 是通过特定 Title ：\d+.\d+.\d+ 并合并到 Main 分支进行版本更新。需要手动确定版本号才能正确推送版本。

• 现在开发流程完善后，有很多不同的诸如 文档更新 脚本修复 等不需要直接发版的 PR。
• 现有的版本推送 PR 标题不够清晰，需要在 commit 中寻找对应的分支 commit 才能发现修复的问题。
• 版本号更新过于繁琐，需要人工确定，容易出现 TAG 冲突发版失败。

目标 & 方案简述

改进 CI：

1. 将原有用正则表达式的 CI 替换为 Label 判断 CI
2. 判断 Label 为 release 之后通过大分支名称确定版本编号，生成对应的版本 tag
3. 触发 Build 动作，推送版本。

后续：

通过 Label 判断 PR 内容可以进一步拓展。如自动生成更新日志，以及文档更新推送等。

方案设计 & 实现步骤

No response

替代方案 & 对比

No response

[zthxxx]

Alternative Ideas:

• 考虑直接 push git tag 后触发 release 么？ 先有 tag 后有 release，手动管理，打 tag 不会冲突， 变成「主干开发，分支发布」的模式

• 写一个 GitHub Action 来升级 patch 版号和发布，做成可手动触发， 需要的时候可以直接点一下就升级 patch 版本和构建发布，<Major>.<Minor> 版号依旧手动更新， 这个 Action 也写成能被其他模式调用，这样也能支持自动化

---

疑问：

• 这个 CI 改动阶段在 3.1 发版之前还是之后？

[EstrellaXD]

Alternative Ideas:

• 考虑直接 push git tag 后触发 release 么？ 先有 tag 后有 release，手动管理，打 tag 不会冲突， 变成「主干开发，分支发布」的模式
• 写一个 GitHub Action 来升级 patch 版号和发布，做成可手动触发， 需要的时候可以直接点一下就升级 patch 版本和构建发布，<Major>.<Minor> 版号依旧手动更新， 这个 Action 也写成能被其他模式调用，这样也能支持自动化

之前是这样做的 ，不过直接 push tag 之后没办法自动生成 release 日志。这个部分有没有更好的解决方案捏。

1. 发布之前 想了想还是发布之后吧

[zthxxx]

我之前的一些实践是先 tag 后 publish release，ChangeLog 是在 tag 之前生成的，

在前端 monorepo 实践中，ChangeLog 的生成方式通常有两种，

1. 自动根据 commit message 生成 (对开发素养要求比较高，要求 commit message 都是有意义的
2. 根据 预先提交的 开发阶段手动写的 changefiles 生成，代表是
   • changesets
   • rushjs

在 2. 的这类场景下，tag 可由开发者手动打，也可由 changesets/rush 的 CI 来自动打 tag 和 push tag

monorepo version with git flow | Excalidraw

[zthxxx]

FYI 参考一下：

PR to release (edge):

• https://github.com/nuxt/nuxt/blob/main/.github/workflows/release-pr.yml

tag to release:

• https://github.com/vuejs/core/blob/main/.github/workflows/release-tag.yml
• https://github.com/vueuse/vueuse/blob/main/.github/workflows/publish.yml

ChangeLog after release:

• https://github.com/vitest-dev/vitest/blob/main/.github/workflows/release.yml

[zthxxx]

我倾向于使用 “流程画出来最简单的那种” 🌝，或者晚上上 figjam 画画

[EstrellaXD]

我倾向于使用 “流程画出来最简单的那种” 🌝，或者晚上上 figjam 画画 sticker.webm OK

[zthxxx]

@EstrellaXD 梳理了一下诉求，应该说要解决的核心痛点是两件事：

• 方便的命令自动升级 patch 版本，不要手动写版本号
• 能相对自动的生成 ChangeLog (Release Log)，不用在发版的时候手动写

---

这样的话，虽然 python 生态不太了解，但是对应的前端解决方案有很多，

先假设根据之前提的可以接受「不用 PR 发版，用 tag 发版」，那么考虑：

• pnpm/npm version patch 就能直接做到 自动升级 patch 版号、自动 commit 并打对应版本 git tag
  • 配合 preversion hook 能在之前触发生成 changelog
• 在 ChangeLog 无法完全根据 commit 全自动生成的情况下，可稍微渐进一点，变成半自动模式， 即日常开发时写 changefiles，升级版本时 preversion 时自动消费 changefiles 来自动生成 ChangeLog 内容再被 commit & tag
• CI 流程差不多，就是根据 tag 来触发构建、生成 GitHub Release Note、推送 docker 等

---

需要做的改动：

1. 把当前仓库变成明确的 monorepo 管理方式，

   • 比如如上说是基于 pnpm workspace 项目根目录饭 package.json 管理，
   • workspace 管理项目根目录 ./、docs/ ，webui/ ，python 的 backend 目录可纳入管理，可不纳入；

2. 这样 backend 中不在写 version，实际 version 在顶层 package.json，

   • 启动或构建时通过脚本读 json 文件来把 version 写入环境变量，python 中读环境变量作为版本
   • 或者是 python 中直接读 ../../package.json 文件来获得版本
   • 总之核心就是中心化版本，统一维护，只由固定命令更新 (pnpm verion patch)

3. CI 改动、changefiles 配置等

[EstrellaXD]

总结一下我这边的

如果是 PR 推送版本

优点

1. 目前 CI 的修改部分较少
2. 有一些现成的工具生成 ChangeLog 如： Release Drafter
3. 推送版本之前可以先经过 CI test

缺点

1. 只能维持分支开发主干推送的模式（但是相对的可以保证主干分支是一个一直可用的版本）
2. changefiles 撰写比较累

---

RFC 的提案是想做一点微调，目前的模式是通过 PR 的 Title 判断是否推送版本，更改为 Label 判断，同时可以自动生成版本号。 Changefile 这个我也觉得目前的模式不够优雅，本身我的 commit 习惯也不够好。

可以对比一下讨论是否更改整个发版流程。

[zthxxx]

RFC 的提案是想做一点微调

我建议是对 CI 的改动不用有“心理负担” 🌝， 因为根据之前仓库里改动的经验，虽然想的是 「微调」，但一般都十几个 commit 和测试才能完成 🌝。

---

只对于 CI 中 publish 本身的过程来说，PR 和 tag 触发没有本质区别，只是一个本地触发、一个由其他 action 触发，

但 ChangeLog 的内容也总是要有出处的，如果 commit 不为 ChangeLog 写的话，那么事后总得手动去写(或者根据半自动生成去调整)，这样最后“去写 ChangeLog 的过程”就是一个需要接受的工作量。

[zthxxx]

@EstrellaXD 疑问：

现在流程中，我们看到的发版的 PR 是自动生成的，只是你手动提的呀？😂

(我一直理解是自动的

[EstrellaXD]

@EstrellaXD 疑问：

现在流程中，我们看到的发版的 PR 是自动生成的，只是你手动提的呀？😂

(我一直理解是自动的

目前还是手动的😂

[zthxxx]

噢 😯，我记忆中是之前群里问的时候说自动，看来记错了 😂

那看来现在 “最小改动量” 是不是就在 CI 流程前置加一个 action 单独来跑 Release Drafter 帮你手动生成 PR？

实际版本改动在它的 PR 中，还是在之后的 action 中修改再 push？

[EstrellaXD]

那看来现在 “最小改动量” 是不是就在 CI 流程前置加一个 action 单独来跑 Release Drafter 帮你手动生成 PR？

Release Drafter 只是我上述举例用的，实际感觉比较依赖分支开发和每次 PR 的规范性。实际感觉也可以换别的方式。我觉得还是通过手动 PR 和 Merge 的方式去出发发版，只不过后续的 Release Note 和版本 Tag 可以自动生成。