Go (Golang) 工具之自动化版本工具 gsemver | semver 语义化版本规范

最新推荐文章于 2024-05-24 17:09:00 发布

西京刀客

最新推荐文章于 2024-05-24 17:09:00 发布

阅读量1.7k

点赞数 2

分类专栏： # golang常用库（Go Repositories） Go # 开发工具文章标签： golang git

本文链接：https://blog.csdn.net/inthat/article/details/123961338

版权

开发工具同时被 3 个专栏收录

119 篇文章 6 订阅

订阅专栏

101 篇文章 44 订阅

订阅专栏

golang常用库（Go Repositories）

34 篇文章 16 订阅

订阅专栏

Go (Golang) 工具之gsemver

什么是gsemver

https://github.com/arnaud-deprez/gsemver

gsemver 是在Go（golang）中开发的命令行工具，它使用Git commit 自动化生成兼容Semver 2.0.0规范的下一个版本。

Semantic Version是当下被大多数软件/库使用的一套版本命名规范。

semver 是语义化版本（Semantic Versioning）规范的一个实现，目前是由 npm 的团队维护，实现了版本和版本范围的解析、计算、比较。

而gsemver 是go版本的语义化版本（Semantic Versioning）规范的一个实现。

动机

为什么另一个git版本工具？

当您尝试从不同的语言（Java，Go，JavaScript等）来实现Devops管道以获取应用程序和库（Java，Go，JavaScript等）时，您始终需要从要将应用程序/库释放到生产中的部署的那一刻起，您始终需要处理版本。

随着Devops全部自动化，您需要一种自动化您的下一个版本的方法。

那么，你有2个选择：

您可以使用没有人类有意义的信息：
- forever increment a number
- use git commit hash
- use build number injected by your CI server
- etc.
您可以使用诸如 semver 规范，一个有意义的公约。

第一个选项很容易，不需要任何工具。

然而，一些工具/技术要求您使用Semver兼容格式版本（例如，go modules, helm等）。您仍然可以使用major, minor or patch ，但是您的版本在您的版本中并不有意义，只是做一个符合规范格式的黑客，而不是使用Spec语义。

因此，对于第二种选项，为了通过遵循规范语义来提供人类有意义的信息，您需要依靠一些约定。

您可以找到一些Git惯例，如：

conventional commits: generalization of angular commit convention to other projects
angular commit convention
gitflow

然后我寻找现有工具，到目前为止，这里是我发现的详尽清单：

GitVersion: tool written in .NET.
semantic-release: tool for npm
standard-version: tool for npm
jgitver: CLI running on java, maven and gradle plugins.
hartym/git-semver: git plugin written in python.
markchalloner/git-semver: another git plugin written in bash
semver-maven-plugin

所有这些工具至少有其中一个问题：

他们依靠运行时环境（NodeJs，Python，Java）。但是，如果我想在另一个运行时建立一个应用程序怎么办？在VM上，这可能不是一个大的事情，而是在我们尝试保持它们尽可能小的容器中，这可能很烦人。
它们不是根据惯例自动生成新版本的。相反，您必须指定要击中的数字（主要，次要，修补程序）和/或您要生成的版本类型（Alpha，Beta，Build等）
它们管理完整的发布生命周期，因此它们紧紧地耦合到某些构建工具，如NPM，Maven或Gradle等。

我发现了一些go 写的库，但他们不处理Git commits/tags约定：

hashicorp/go-version
coreos/go-semver
Masterminds/semver
blang/semver

我需要一个工具来基于以前的 git tag 生成下一个版本Semver兼容版本，我可以在每种类型的应用程序/库上使用，因此不依赖于特定的运行时环境。

这就是为什么我决定使用go，我们发现的工具的灵感基础上来构建此工具。

感谢

我还要感谢2个与gsemver结合使用的项目，以更好地自动化此工具：

conventional commits a commit convention I’ve decided to adopt in all my commits.
git-chglog is a customizable CHANGELOG generator implemented in go based on commits log.
GoGeleaser is a release automation tool for Go projects.

使用这3个工具和gsemver，它会更容易自动化您的项目。

gsemver 安装

安装

go get -u github.com/arnaud-deprez/gsemver

对于手动安装，您可以从发布页面下载二进制文件并将其放在$ Path目录中。

$ gsemver version
# output the gsemver version

gsemver 使用

准备

大多数CI系统- 默认 - shallow git clone 仓库。

由于gsemver 目前使用git describe 来计算下一个版本，它需要访问整个历史记录或至少到最后一个父tag。因此，gsemver 将在计算下一个版本之前执行git fetch --tags。

[root@dev iam]# git fetch --tags
remote: Enumerating objects: 5698, done.
remote: Counting objects: 100% (5696/5696), done.
remote: Compressing objects: 100% (1470/1470), done.
remote: Total 5125 (delta 3712), reused 4778 (delta 3422), pack-reused 0
Receiving objects: 100% (5125/5125), 1.51 MiB | 3.29 MiB/s, done.
Resolving deltas: 100% (3712/3712), completed with 349 local objects.
From https://github.com/marmotedu/iam
 * [new tag]         v1.0.0     -> v1.0.0
 * [new tag]         v1.0.1     -> v1.0.1
 * [new tag]         v1.0.10    -> v1.0.10
 * [new tag]         v1.0.2     -> v1.0.2
 * [new tag]         v1.0.3     -> v1.0.3
 * [new tag]         v1.0.4     -> v1.0.4
 * [new tag]         v1.0.5     -> v1.0.5
 * [new tag]         v1.0.6     -> v1.0.6
 * [new tag]         v1.0.8     -> v1.0.8
 * [new tag]         v1.1.0     -> v1.1.0
 * [new tag]         v1.2.0     -> v1.2.0
 * [new tag]         v1.4.0     -> v1.4.0
 * [new tag]         v1.6.0     -> v1.6.0
[root@dev iam]#

随着gsemver 还需要知道当前分支，它试图用git symbolic-ref HEAD命令获取它。然而，大多数CI系统在从HEAD 状态分离时执行构建，在git中变得困难以从触发构建的位置获取分支。幸运的是，大多数CI服务器将分支名称注入环境变量中。这就是gsemver 允许您将GIT_BRANCH 环境变量作为备份解决方案使用的原因。

git HEAD 基础

HEAD是一个符号引用，他指向你正在工作的分支，他总是指向你最近的一次提交记录，如果想看 HEAD 指向，可以通过 cat .git/HEAD 查看，如果 HEAD 指向的是一个引用，还可以用 git symbolic-ref HEAD 查看它的指向。可以使用git checkout 提交记录对应的hash值，来切换到对应的提交上，可以使用git log来查看对应的提交和hash值。

git checkout 分支名^ HEAD指向该分支的本次提交记录的上一次提交。
git checkout 分支名~3 HEAD指向该分支的本次提交记录的上上上次提交。

CLI

自动化生成版本

gsemver bump

这将使用git commits convention 来生成下一个版本。

唯一受支持的约定是conventional commits。它也默认使用默认master 和release/*默认为发布分支，它会生成带有不匹配的任何分支的构建元数据的版本。这是当前的一个限制，但路线图是制作更可配置的。

conventional commits integration tests显示您的depth如何生成版本。如下：

*   34385d9 (HEAD -> master, tag: v1.2.2) Merge from feature/merge2-release-1.1.x
|\  
| *   b884197 Merge from release/1.1.x
| |\  
|/ /  
| *   869c83f (tag: v1.1.3, release/1.1.x) Merge from fix/fix-3
| |\  
| | * 22eabaf fix: my bug fix 3 on release/1.1.x
| |/  
* |   704fde4 (tag: v1.2.1) Merge from feature/merge-release-1.1.x
|\ \  
| * \   61b6a7c Merge from release/1.1.x
| |\ \  
|/ / /  
| | _   
| *   f2d9b5e (tag: v1.1.2) Merge from fix/fix-2
| |\  
| | * f95ccbe fix: my bug fix 2 on release/1.1.x
| |/  
* |   99a3662 (tag: v1.2.0) Merge from feature/awesome-3
|\ \  
| |/  
|/|   
| * cc6c1ed feat: my awesome 3rd change
|/  
*   145cbff (tag: v1.1.1) Merge from bug/fix-1
|\  
| * 681a11b fix: my bug fix on master
|/  
*   e9e7644 (tag: v1.1.0) Merge from feature/awesome-2
|\  
| * f30042e feat: my awesome 2nd change
|/  
*   fba50a2 (tag: v1.0.0, tag: v0.2.0) Merge from feature/awesome-1
|\  
| * bf05218 feat: my awesome change
|/  
* c619bff (tag: v0.1.1) fix(doc): fix documentation
* 128a5d9 (tag: v0.1.0) feat: add README.md

手动版本包

gsemver bump major
gsemver bump minor
gsemver bump patch

配置文件

您还可以使用配置文件来定义自己的规则。默认情况下，它将查找.gsemver.yaml或then in $ home / .gsemver.yaml中的文件，但您可以通过–config（或-c）选项来指定自己的配置文件：

gsemver --config my-config.yaml
# or
gsemver -c my-config.yaml

配置文件格式如下所示：

majorPattern: "(?m)^BREAKING CHANGE:.*$"
minorPattern: "^feat(?:\(.+\))?:.*"
bumpStrategies:
- branchesPattern: "^(master|release/.*)$"
  strategy: "AUTO"
  preRelease: false
  preReleaseTemplate:
  preReleaseOverwrite: false
  buildMetadataTemplate:
- branchesPattern: ".*"
  strategy: "AUTO"
  preRelease: false
  preReleaseTemplate:
  preReleaseOverwrite: false
  buildMetadataTemplate: "{{.Commits | len}}.{{(.Commits | first).Hash.Short}}"

这是用于传统提交的默认配置。您可以根据需要调整配置。

bumpStrategies 是按顺序应用的，直到一个与当前分支的branchesPattern 正则表达式匹配。这允许您根据自己的 git flow定义您的策略。

语义化版本 2.0.0

官方原文：https://semver.org/lang/zh-CN/

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：

主版本号：当你做了不兼容的 API 修改，
次版本号：当你做了向下兼容的功能性新增，
修订号：当你做了向下兼容的问题修正。
先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。

考虑使用这样的版本号格式：X.Y.Z（主版本号.次版本号.修订号）修复问题但不影响 API 时，递增修订号；API 保持向下兼容的新增及修改时，递增次版本号；进行不向下兼容的修改时，递增主版本号。

主版本号为零（0.y.z）的软件处于开发初始阶段，一切都可能随时被改变。这样的公共 API 不应该被视为稳定版。

1.0.0 的版本号用于界定公共 API 的形成。这一版本之后所有的版本号更新都基于公共 API 及其修改内容。

语义化版本控制规范（SemVer）
语义化版本控制的规范是由 Gravatars 创办者兼 GitHub 共同创办者 Tom Preston-Werner 所建立。

该章节直接查看，官方 https://semver.org/lang/zh-CN/ 即可。

西京刀客

关注

2
点赞
踩
1

收藏

觉得还不错? 一键收藏
打赏
1
评论
Go (Golang) 工具之自动化版本工具 gsemver | semver 语义化版本规范

gsemver 是在Go（golang）中开发的命令行工具，它使用Git commit 自动化生成兼容Semver 2.0.0规范的下一个版本。
复制链接

扫一扫