标签: gitversion

我最近开始使用GitVersion来编写我的程序集,我喜欢它!

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

  <!-- [TPL] name the output file to include the version from theLocalServer assembly -->
  <Target Name="BeforeBuild">
    <GetAssemblyIdentity AssemblyFiles="$(SolutionDir)BuildOutput\$(Configuration)\TA.DigitalDomeworks.Server.exe">
      <Output TaskParameter="Assemblies" ItemName="AssemblyVersions" />
    </GetAssemblyIdentity>
    <CreateProperty Value="$(OutputName).%(AssemblyVersions.Version)">
      <Output TaskParameter="Value" PropertyName="TargetName" />
    </CreateProperty>
    <CreateProperty Value="$(TargetName)$(TargetExt)">
      <Output TaskParameter="Value" PropertyName="TargetFileName" />
    </CreateProperty>
    <CreateProperty Value="$(TargetDir)$(TargetFileName)">
      <Output TaskParameter="Value" PropertyName="TargetPath" />
    </CreateProperty>
  </Target>

这将生成一个名为的输出文件:

TA.DigitalDomeworks.Installer.7.1.0.3.msi

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

但是,我真正喜欢的是使用该FullSemVer属性,可以在这里看到:

C:\Users\Tim\source\repos\TA.DigitalDomeworks [release/7.1 ?1 +0 ~1 -0 !]> gitversion
{
  "Major":7,
  "Minor":1,
  "Patch":0,
  "PreReleaseTag":"beta.3", …

我正在尝试使用由 GitVersion 在成功构建结束时的 GIT 提交确定的当前版本号设置标签。感觉我不能成为第一个这样做的人，但我正在努力寻找有用的东西。

Azure Devops Pipeline 在成功时获取源以“标记源”中有一项功能。我已经设置了它并设置为由我拥有的代理任务之一设置的变量（GitVersion）

我可以在调试日志中看到这个变量是由我添加到管道的 GitVersion 组件设置的。

2019-12-06T20:54:20.2390794Z ##[debug]Processed: ##vso[task.setvariable variable=GitVersion.MajorMinorPatch;]2.98.0

但是，如果我就这样保留它，我会得到一个创建为“v$(GitVersion.MajorMinorPatch)”的标记，这意味着在创建标记时该变量不再存在。

标签格式帮助工具提示说

“标签格式可以是用户定义或预定义变量的组合，其范围为“全部”。例如：'$(Build.DefinitionName) $(Build.DefinitionVersion) $(Build.BuildId) $(Build .BuildNumber) $(My.Variable)'"

所以我猜问题是在管道期间创建的这个变量没有 All 的范围。

然后我尝试向“GitVersion.MajorMinorPatch”的管道添加一个管道变量，希望这是在正确的范围内，并希望当“task.setvariable”命令运行时，这会将这个变量值设置得更高范围变量。

但是在这种情况下，我只是创建了一个标签“v”。

所以我有点卡住了。不知何故，我需要能够在范围 ALL 上动态创建或设置一个变量，并使用我想在此处标记的值。

我真的很感激对此的任何想法。

我正在使用TeamCity 2017.1.4和GitVersion.

teamcity项目本身由许多构建配置组成,第一个构建配置是运行GitVersion,然后所有后续步骤都依赖于此步骤的快照,并从其参数中提取版本.

在大多数情况下,这很有效,但是如果我们创建一个新的分支,例如./ release-foo并推送这个,teamcity不会触发构建因为它之前已经构建了commit sha,不幸的是我们需要它再次触发,即使提交没有改变是在新分支中意味着它会得到一个不同的GitVersion号码.

我已经尝试强制GitVersion构建配置上的快照依赖项总是被重建,但这似乎有点难看,因为它会破坏所有其他不是问题的场景.我也知道我可以手动触发构建,告诉它重建所有依赖项并且它会工作,但是我很好奇是否有更好的方法来让teamcity自动触发分支上的提交构建,如果该分支没有以前存在,或者实际上我可以采用任何其他方式.

我正在尝试构建一些具有由setuptools-git-versioning. 不幸的是，即使遵循文档和极少数的在线资源，我也无法使这个版本控制工作。

pyproject.toml:

[build-system]
requires = ["setuptools>=42", "wheel", "setuptools-git-versioning"]
build-backend = "setuptools.build_meta"

[tool.setuptools-git-versioning]
enabled = true

...

[project]
version = "1.0"
...

根据文档，该enabled标志应该足以setuptools获取基于标签的版本并将其设置为包的版本，但是在构建包时，运行时提示的版本python3 -m pip list或对应于部分conda list中版本的硬编码值project的pyproject.toml。

我错过了什么/做错了什么？

通过 AzureDevops 运行 GitVersion，并在尝试在除 master 之外的任何分支（包括拉取请求分支等）上使用时收到以下错误消息；

到目前为止，我已尝试通过以下方式解决该问题：

• 增加结账深度
• 通过 next-version 设置手动指定下一个版本

错误：

 Gitversion could not determine which branch to treat as the development branch

Git版本文件

mode: Mainline
branches: 
  master:
    regex: master
    increment: Patch
assembly-informational-format: '{MajorMinorPatch}+Branch.{BranchName}{PreReleaseTag}'
major-version-bump-message: '\+semver:\s?(breaking|major)'
minor-version-bump-message: '\+semver:\s?(feature|minor)'
patch-version-bump-message: '\+semver:\s?(fix|patch)'
commit-message-incrementing: Enabled
tag-prefix: '[vV]'
ignore:
  sha: []

YAML 管道

- task: gitversion/setup@0
  displayName: gitversion/setup
  inputs:
    versionSpec: '5.10.3'

- task: gitversion/execute@0
  displayName: gitversion/execute
  inputs:
    useConfigFile: true
    configFilePath: GitVersion.yml

目前我有一个 react native 应用程序，我遇到的问题是在每次构建或提交时更新版本非常耗时。

此外，我启用了 Sentry，因此每次构建时，某些构建都会获得相同的版本，因此某些崩溃很难确定它们来自何处。

最后，手动更新版本容易出错。

我如何设置我的构建以在每次构建并忘记所有这些手动任务时生成自动版本？

我们已经使用 Bamboo 构建服务器有一段时间了，并且安装了 GitVersion，因此可以将其选为构建计划中的任务。运行任务时，我们通常使用 /UpdateAssembleInfo 参数。对于.NET Framework项目，这将使用bamboo版本控制设置更新源中的程序集信息文件，以便.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/我尝试运行

gitversion.exe /UpdateAssemblyInfo MyProjectName.AssemblyInfo.cs /EnsureAssemblyInfo 

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

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

有任何想法吗？

是否有在monorepos中使用版本标签的标准？是否符合1.0.0-myapp1和2.1.0-myapp2可接受的东西？还是有另一种方法来区分应用程序之间的版本？

我们的 CI 构建的 GitVersion 步骤现在需要 4-5 分钟，我们无法真正弄清楚原因。以下是一些基本日志：

2018-09-25T14:31:02.4222252Z ##[section]Starting: GitVersion
2018-09-25T14:31:02.4227925Z ==============================================================================
2018-09-25T14:31:02.4228168Z Task         : GitVersion Task
2018-09-25T14:31:02.4228396Z Description  : Easy Semantic Versioning (http://semver.org) for projects using Git
2018-09-25T14:31:02.4228654Z Version      : 3.6.5
2018-09-25T14:31:02.4229010Z Author       : GitVersion Contributors
2018-09-25T14:31:02.4229302Z Help         : See the [documentation](http://gitversion.readthedocs.org/en/latest/) for help
2018-09-25T14:31:02.4229565Z ==============================================================================
2018-09-25T14:31:02.4366228Z Preparing task execution handler.
2018-09-25T14:31:02.6709097Z Executing the powershell script: d:\w\_tasks\GitVersion_e5983830-3f75-11e5-82ed-81492570a08e\3.6.5\GitVersion.ps1
2018-09-25T14:31:03.0124372Z Current Directory:  D:\w\_tasks\GitVersion_e5983830-3f75-11e5-82ed-81492570a08e\3.6.5
2018-09-25T14:31:03.0124924Z 
2018-09-25T14:31:03.0125184Z 
2018-09-25T14:31:03.0130879Z Sources Directory:  d:\w\1\s
2018-09-25T14:31:03.0131239Z 
2018-09-25T14:31:03.0131454Z 
2018-09-25T14:31:03.0230450Z Invoking GitVersion with d:\w\1\s /output buildserver /nofetch
2018-09-25T14:31:03.0231023Z 
2018-09-25T14:31:03.0231265Z …

An unexpected error occurred: System.NullReferenceException: Object reference not set to an instance of an object. at LibGit2Sharp.Core.Handles.ObjectHandle.op_Implicit(ObjectHandle handle) in /_/LibGit2Sharp/Core/Handles/Objects.cs:line 509 at LibGit2Sharp.Core.Proxy.git_commit_author(ObjectHandle obj) in /_/LibGit2Sharp/Core/Proxy.cs:line 289 at 在没有在 yaml 中进行设置的选项的azure devops yaml 管道上运行任务 gitversion/execute 时出现错误 ##[debug]fetchDepth=1 ，因为这已更改为 Microsoft 的默认值。