Automate Git Tag Creation with GitHub Actions

[cubxxw]

Background

While working on the OpenIM project, we've faced challenges with the current manual process of tagging our versions. The manual steps we follow are:

tag -a v3.2.0-beta.0 -s -m "release(v3.2.0): new feat cluster"
git push upstream v3.2.0-beta.0

This process has several shortcomings:

1. Due to our CONTRIBUTING.md guide, direct pushing is not allowed, making this process cumbersome.
2. Our current PR merge strategy often leads to many commits being merged as one PR, causing verbose and complex commit messages that aren't concise for release notes.
3. The process is not automated and requires manual effort, which increases the chance of human error.

Proposed Solution: GitHub Action for Tagging

To address these issues, we propose implementing a GitHub action that automates the process of tagging while adhering to our workflow requirements.

Features:

1. GitOps Integration:
   • If the last digit of the git version number is 0, and there is no build number afterward, it signifies the beginning of a new minor semantic version.
   • The bot will automatically create a branch named release-v*.* and put it under branch protection.
2. ChatOps Integration:
   • Using GitHub API's labels and PR or issue comment logic, we can command the bot to execute actions.
   • By commenting /content git-tag-name, the bot will automatically tag with the name git-tag-name.
   • Adding a specific label to a PR or issue will prompt the bot to auto-increment the current version number by one on the last digit.

Workflow:

1. When a PR is merged or an issue is closed, the action checks the version number.
2. If the last digit is 0, the bot creates a release-v*.* branch and enables branch protection.
3. Through the comment system (ChatOps), developers can instruct the bot to create specific tags.
4. Alternatively, specific labels can be used to auto-increment and tag new version numbers.

Benefits:

• Streamlines the tagging process, making releases more efficient.
• Reduces human errors.
• Consistency in tagging and branching.
• Clear and concise commit messages for release notes.

Next Steps:

1. Draft a clear specification for the GitHub action, defining all triggers and outputs.
2. Identify potential challenges in the existing workflow and how this automation might impact them.
3. Collaborate with team members to gather feedback and iterate on the proposal.

[cubxxw]

背景

在开发 OpenIM 项目时，我们面临着手动打标签的挑战。我们遵循的手动步骤如下：

git tag -a v3.2.0-beta.0 -s -m "release(v3.2.0): new feat cluster"
git push upstream v3.2.0-beta.0

此过程存在几个问题：

1. 根据我们的 CONTRIBUTING.md 指南，不允许直接推送，使此过程变得繁琐。
2. 我们当前的 PR 合并策略经常导致许多提交作为一个 PR 合并，导致冗长和复杂的提交信息，这对于发布说明不是很简洁。
3. 该过程不是自动的，并需要手动努力，这增加了人为错误的机会。

提议的解决方案：打标签的 GitHub Action

为了解决这些问题，我们建议实现一个 GitHub action，自动化打标签的过程，同时遵循我们的工作流要求。

功能：

1. GitOps 集成：
   • 如果 git 版本号的最后一位是 0，并且后面没有编译号，这意味着新的次语义版本的开始。
   • 机器人将自动创建名为 release-v*.* 的分支并启用分支保护。
2. ChatOps 集成：
   • 使用 GitHub API 的标签以及 PR 或问题评论逻辑，我们可以命令机器人执行操作。
   • 通过评论 /content git-tag-name，机器人将自动以 git-tag-name 的名称打标签。
   • 将特定标签添加到 PR 或问题将提示机器人在最后一位上自动增加当前版本号。

工作流：

1. 当 PR 被合并或问题被关闭时，操作检查版本号。
2. 如果最后一位是 0，机器人创建一个 release-v*.* 分支并启用分支保护。
3. 通过评论系统 (ChatOps)，开发人员可以指导机器人创建特定标签。
4. 或者，可以使用特定的标签来自动递增并打新版本号的标签。

好处：

• 简化打标签的过程，使发布更加高效。
• 减少人为错误。
• 打标签和分支的一致性。
• 发布说明的清晰和简洁的提交信息。

下一步：

1. 为 GitHub 操作草拟清晰的规范，定义所有触发器和输出。
2. 确定现有工作流中可能存在的潜在挑战以及这种自动化如何影响它们。
3. 与团队成员合作，收集反馈并对提案进行迭代。

[cubxxw]

Link #639

[cubxxw]

调研：目前市场上并没有针对 gh 做的 actions，可以针对性 gh 工具做一个高度可扩展的 actions，其中以模块化的手段去管理，我认为是一个非常好的事情。

[kubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

Research: At present, there are no actions for gh in the market. It is a very good thing to make highly scalable actions for gh tools and manage them in a modular way.