问题标签 [gitversion]

我想实现 NuGet 包的自动语义版本控制作为 VSTS 构建步骤（实际上在 cakebuild 步骤中）。问题是，虽然获取正在执行的分支构建很容易（buildSystem.TFBuild.Environment.Repository.Branch），但我不知道如何获取有关哪个分支合并到 master 的信息（补丁版本的修补程序分支，或为次要开发具有新功能的分支）。这是可能的还是我应该接受每个版本更新都需要手动 Nuspec 编辑？看起来 gitflow 具有识别这些的内置机制，例如基于分支名称，但我们根本不使用它。

我发现了奇怪的“问题”，或者更确切地说是 GitVersion 的行为。考虑以下：

我们在 dev 分支工作，版本是 0.1.0。我用“+semver：minor”消息向它提交了一些东西。很好，版本增加了，0.2.0，我们可以继续，创建一个包等。我们继续我们的工作，我做了新的更改，再次使用“+semver:minor”提交。但版本仍然是 0.2.0。问题是什么？我想我不明白 gitversion 如何工作或应该如何工作。

即使我尝试从 dev 创建新分支，然后在其中进行凹凸提交，它仍然不会再次增加版本。

我的目标是有一个简单的工作流程：用于发布新包的主分支，我们可以从它分支，添加一些更改，根据带有提交消息的任务类型调整版本，然后将其合并回主控。听起来很简单，但它并没有按预期工作。

我有一个包含 48 个 C# 项目的 Visual Studio 解决方案。现在，我想自动对所有项目进行版本控制，我刚刚将 GitVersionTask 的 Nuget 包添加到所有项目（版本 4.0.0-beta0012）。当我在本地构建解决方案时，一切正常。新构建的二进制文件包含 gitversion 生成的版本信息。

但是当我尝试通过我们的 TFS 构建服务器进行构建时，它正在对分支进行一些操作。这是构建日志的一些压缩输出：

...对于我们远程存储库上的每个分支，都会重复最后一条消息“跳过...的更新，因为它已经与远程引用匹配”。由于这是相当多的分支，对于解决方案中的一个项目，这需要将近一分钟。因此，对于整个解决方案，我们将为此花费将近一小时的时间。

我已经花了很多时间研究这个，但我仍然无法在网上找到任何有用的东西。

有人知道为什么 TFS 将其作为解决方案构建的一部分，而本地 Visual Studio 构建不这样做吗？

需要以下方面的建议：

在我的公司中，我正在开发供外部利益相关者使用的 .NET 类库，并且我在利益相关者可以访问的私有 NuGet 源上共享它们。

这些库依赖于一个核心库，如下所示。目前，我在一个 VS 解决方案中维护这些库，显然是在一个 Git 存储库中。我正在关注 SemVer 对它们进行版本控制。

到目前为止，我一直在 Visual Studio 中手动对它们进行版本控制（每当我需要升级版本时，在 AssemblyInfo.cs 中手动设置正确的值），并在每个项目中使用批处理文件来打包并将该特定库推送到 NuGet。

但现在我最近开始研究 VSTS，我的下一个任务是尽可能地自动化构建和发布，包括自动版本控制。我偶然发现了 GitVersion，我认为它对最后一部分有很大帮助。

但是，这里是但是。如果我理解正确，GitVersion 在存储库级别运行，因此由 GitVersion 计算的给定 semver 版本适用于存储库中的所有程序集/库，对吗？

那么您对这些库的发布和版本控制策略有何建议？

1) 像现在一样将所有内容保存在一个解决方案和存储库中，每当需要发布的一个包（例如 CoreLibrary.Extension1）发生更改时，这也会为所有其他库生成一个 NuGet 包。因此，如果所有包都在 1.0.0 上并且其中一个有一点小变化，它们都会被撞到 v1.1.0 并且都被打包和推送？

2）为每个项目创建一个 git repo 并让 GitVersion 分别在每个 repo 上发挥它的魔力。通过扩展库中的 NuGet 引用 CoreLibrary。

选项 2 是我认为最干净的选项，并且具有按项目处理版本控制和打包的优点，但在维护它们方面可能会大大增加工作量，特别是考虑到我是这些库的唯一开发人员这一事实。

你觉得呢？你有没有什么想法 ？在给定上下文的情况下，您会选择哪个选项？我是否错过了任何其他可能值得考虑的选择？

设置我在自动化构建和发布中的第一步，因此任何建议都非常受欢迎。

谢谢

根据 GitVersion for GitFlow 的文档，开发分支的次要版本应该在创建发布分支时碰撞。据我了解，这应该自动发生吗？( https://gitversion.readthedocs.io/en/latest/git-branching-strategies/gitflow-examples/ ) - 查看次要/主要版本分支

我目前正在使用 GitVersion 3.6.5 （因为这是随 VSTS GitVersion 任务安装的版本）

我创建了一个小型测试存储库，如下所示：

• 混帐初始化
• 【大师】触摸helloworld.txt
• [主] git add --all
• [master] git commit -m "添加的文件"
• [主] git 标签 0.1.0
• [大师] git checkout -b 开发
• [开发] touch helloworld.txt
• [开发] git add --all
• [开发] git commit -m "更新文件"
• [开发] gitversion --> 报告 0.2.0.unstable.# (OK)
• [开发] git checkout -b release/0.2.0
• [release/0.2.0] 触摸helloworld.txt
• [发布/0.2.0] git add --all
• [release/0.2.0] git commit -m "更新文件"
• [release/0.2.0] gitversion --> 报告 0.2.0.beta.# (OK)
• [release/0.2.0] git checkout 开发
• [开发] touch helloworld.txt
• [开发] git add --all
• [开发] git commit -m "再次更新文件"
• [开发] gitversion --> 报告 0.2.0.unstable.# (错误)

最后一个 gitversion 命令，我希望它报告 0.3.0.unstable.#，因为存在 0.2.0 的发布分支

为什么在我创建发布分支并提交后，开发人员没有报告次要版本的增加？！

我们已经使用 Bamboo 构建服务器一段时间了，并且我们安装了 GitVersion，因此可以将其选为构建计划中的任务。我们通常在运行任务时使用 /UpdateAssembleInfo 参数。对于 .NET Framework 项目，这将使用竹版本控制设置更新源中的 assemblyinfo 文件，因此 .NET 程序集具有与我们的 Bamboo 构建和后续 Bamboo 部署相同的版本信息，使我们能够了解已部署项目的版本通过检查程序集文件属性的字段。这一切都运作良好。

但是，我们现在正在构建和部署 .NET Core 2.0 解决方案，并且发现 GitVersion /UpdateAssemblyInfo 无法正常工作。

我搜索了 .NET Core 的修复程序，但只能找到涉及使用 project.json 文件的解决方案，该文件不再与 .NET Core 2.0 一起使用（它已更改为 *.csproj 文件）。

我查看了http://gitversion.readthedocs.io/en/latest/usage/command-line/并尝试运行

其中 MyProjectName 表示 .NET Core 2.0 ..\\obj\release\netcoreapp2.0 文件夹中的 assemblyinfo.cs 文件的实际项目名称后缀。但它没有更新该文件。

我不得不假设必须有一个将 GitVersion 与 Bamboo 和 .NET Core 2.0 一起使用的解决方案，但我很难找到一个解决方案。

有任何想法吗？

I am looking for a way to use semantic versioning to have $(Major).$(Minor).$(Fix) on the file version of my project dll as well as on TFS2015. I succeeded to have it but now I face other troubles (see below)

I use the following lines in the .csproj which works very well to apply the buildnumber created by gitversion task:

The problem is that I am using an agent so it makes it a bit more difficult it seems that config is in .git\gitversion_cache*.yml.

I have read ton of documentation and currently I am able to use this .yml file but it looks like it is generated on the agent and then it is not replaced with default values 0.0.1+26.

So :
1) should I commit the yml config file or have it in a specific folder in the agent ? If on the agent how to tell tfs2015 where it is located ? The agent build directory is sometimes cleaned...
2) how you can auto-increment the $(Fix) variable?
3) how to have a command line to increase major and minor when there is a change? I could not find any information...

Regards,

我目前正在尝试GitFlow在GitLab测试项目中实现，然后从 TeamCity 运行构建。

我已经配置了我的GitVersion.yml文件，这样当我从开发版本 0.3.0-alpha.3 创建一个发布分支（例如 release/0.3.0）然后提交到开发时，开发上的次要版本应该增加（例如 0.4. 0-alpha.1)。但是当我在 TeamCity 上构建开发时，它的版本为 0.3.0-alpha.4，我需要先构建发布分支，然后重新构建开发以获得正确的版本 0.4.0-alpha.1。

有没有办法GitVersion在不首先构建发布分支的情况下计算 TeamCity 中开发分支构建的正确版本？我想避免开发人员构建开发并将错误版本的包推送到八达通服务器的可能性。

软件版本：

• TeamCity： 2017.2.4（内部版本 51228）和 2018.1（内部版本 58245）
• GitVersion： v4.0.0-beta0012

我最近开始使用GitVersion对我的程序集进行版本控制，我喜欢它！

我喜欢生成一个.msi反映正在构建的产品版本的文件。到目前为止，我在我的.wixproj文件中使用了这个：

这将生成一个名称如下的输出文件：

TA.DigitalDomeworks.Installer.7.1.0.3.msi

我从这个答案中找到了这个解决方案，它引用了这篇博文。来自7.1.0.3构建中主程序集的程序集版本，而 GitVersion 在其自己的构建过程中又对其进行版本控制。

但是，我真正想要的是使用该FullSemVer属性，可以在这里看到：

所以我想看到的最终文件名是：

TA.DigitalDomeworks.Installer-7.1.0-Beta.3.msi

在 GitVersion 文档中，它说我需要确保GitVersion.GetVersion构建任务已执行，之后我应该能够从名为$(GitVersion_FullSemVer).

但是，我不确定如何在 WiX 项目中实现这一点，因为安装GitVersionTaskNuGet 包似乎没有做任何事情（在 C# 项目中，一切都只是神奇地工作）。如果我能达到可以执行任务的地步GitVersion.GetVersion，那么我想我可以清楚地看到获得我想要的输出名称的方式。

有没有人有这个工作？或者任何人都可以就如何解决这个问题提供任何建议？

我需要GitVersion.exe在我的 Jenkins 管道中获取变量。

GitVersion文档给出了如何做到这一点的提示。本质上调用gitversion /output buildserver.

此调用确实将变量添加到当前步骤，并且一旦步骤完成，它们就会丢失。set我可以显示在同一 bat 执行中组合命令时执行此调用。第二个set显示变量已从环境中消失。

GitVersion 的文档知道这一点并建议使用EnvInject。安装插件并执行相同的管道并没有改变结果。我读到插件不是为管道制作的，因此可能与它有关。

管道支持environment的语法。

按照该语法，我可以在管道顶部设置静态变量，如下所示：

我需要的是组合这些调用，以便我可以将运行时变量添加到 Jenkinsfile pupeline。

现在显然上面的调用甚至语法都不正确。有没有办法标记一个部分，以便包含的环境更改可用于其他步骤？

编辑：这仍然没有解决。目前我需要创建一个批处理脚本并将该工具作为参数传递给它。在批处理中，我可以调用该工具以添加到批处理脚本的环境中，并在批处理运行时使用它。如果流程在所有多行上保持相同，则 Jenkins 文件中的多行批处理可能是一种解决方案。