0

我正在使用 GitVersion（如果重要的话，版本 3.5.3），并得到了一些意想不到的结果；特别是生产的版本有一个意外的提交计数部分。查看日志我可以看到提交计数计算正确，但 GitVersion 使用的基本版本是错误的（或者至少不是我认为的那样）。

然而 GitVersion 的日志文件并没有什么帮助，它只是列出了一系列标签，然后是一长串合并基础，最后它只是说明它决定使用哪个基础版本。

GitVersion 可以让我知道为什么它选择了那个特定的基本版本吗？

4

1 回答 1

1

我不确定，您是否已经检查过；但在他们的文档中解释了他们如何计算基本版本和新版本

更新：添加了文档中的主要信息。

建筑学

GitVersion 在 v3.0 中具有三个不同的计算版本的步骤。

  • 如果标记了当前提交，则使用该标记并添加构建元数据（不包括提交计数）。其他两个步骤不会执行
  • 评估一组策略以决定基本版本和有关该版本的一些元数据。这些策略包括 HighestReachableTag、NextVersionInConfig、MergedBranchWithVersion、VersionInBranchName 等
  • 选择最高的基本版本，使用该基本版本计算新版本。

从视觉上看，它看起来像这样： 在此处输入图像描述

基本版本策略

  • HighestTagBaseVersionStrategy - 从当前分支中找到最高可达标签
  • VersionInBranchBaseVersionStrategy - 从分支名称中提取版本信息。例如 release/3.0.0 会找到 3.0.0
  • ConfigNextVersionBaseVersionStrategy - 从 GitVersion.yaml 文件返回版本
  • MergeMes​​sageBaseVersionStrategy - 从合并消息中查找版本号。例如。 将'release/3.0.0' 合并到 'master'将返回3.0.0
  • FallbackBaseVersionStrategy - 总是为新存储库返回 0.1.0

每个策略都需要返回一个具有以下属性的 BaseVersion 实例

  • 来源- 来源的描述。例如 `Merge message 'Merge 'release/3.0.0' into 'master''
  • ShouldIncrement - 一些策略应该增加版本，而另一些则不需要。例如 ConfigNextVersionBaseVersionStrategy 返回 false，HighestTagBaseVersionStrategy返回 true
  • SemanticVersion - 基本版本策略的 SemVer
  • BaseVersionSource - 沙的来源。Commits 将从这个 Sha 开始计算。可以为 null（例如 ConfigNextVersionBaseVersionStrategy 返回 null）
  • BranchNameOverride - 当标签配置中使用useBranchName或{BranchName}时，这允许分支名称被基础版本更改。VersionInBranchBaseVersionStrategy 使用它来删除第一个 - 或 / 之前的任何内容。所以 foo 最终被评估为 foo。如果有疑问，只需使用 null
于 2017-01-31T16:02:13.950 回答