Use convention to derive a SemVer product version from a GitFlow based repository
arturcic on 5.3.6
I can put sha in the ignore list, but the problem is that some of those with the commit messages are also the ones that are tagged
$ git log 2.0.0
commit a3079c986ec4df96eb50c2dcee5a575409e98084
Merge: 3bc4e9a 3ce74dd
Author: Foo Bar <foo@bar.baz>
Date: Thu May 14 23:10:59 2020 -0400
Merge branch 'release/2020.5-giant-project'
so if I ignore that sha to avoid that merge commit message, it also ignores the tag
1.ProcessExitCode(Int32 exitCode)
[08:11:36][Version] at Cake.Core.Tooling.Tool
1.Run(TSettings settings, ProcessArgumentBuilder arguments, ProcessSettings processSettings, Action`1 postAction)Hi, I've got a question around using GitVersion and NuGet packaging via dotnet pack
.
When GitVersion determines BuildMetaData
should have a value, this in turn affects the FullSemVer
to include it.
Eg: Imaging current version is v1.2.4 and we are on a release branch with no tag yet, if GitVersion calculates BuildMetaData=4
when I dotnet pack
this will set FullSemVer=1.2.4-beta1+4
.
This becomes an issue for NuGet packages, as the .nuspec
file's <version>
property will use the FullSemVer
(ie: 1.2.4-beta1+4) but the filename of the nupkg will be UsefulLib.1.2.4-beta1.nupkg
as NuGet with normalise the filename and drop the metadata (https://github.com/NuGet/Home/wiki/SemVer-2.0.0-support#pack).
However now if I do another follow-on build of the same commit thenBuildMetaData=5
, FullSemVer=1.2.4-beta1+5
and .nuspec
file's <version>
property will use the FullSemVer
(ie: 1.2.4-beta1+5) . BUT the nupkg filename will conflict with the previous UsefulLib.1.2.4-beta1.nupkg
Has anyone dealt with this issue?
hi everyone, I'm trying to use GitVersion with Nuke Build within a DevOps Pipeline. Do I really need to install the UseGitVersion extension from Marketplace to be able to inject the variables in the code as
[GitVersion] readonly GitVersion GitVersion;
? For now I'm getting the following error:
> C:\Users\VssAdministrator\.nuget\packages\gitversion.commandline\5.3.4\tools\gitversion.exe
##[error]Process 'gitversion.exe' exited with code 1.
Hi.
I noticed one trouble in version 5.3.4.
I have some c# projects on .net Core and .net Standard in one solution.
And I have “Directory.Build.props” in core directory of solution
with content<Project>
<PropertyGroup>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
<UpdateAssemblyInfo>true</UpdateAssemblyInfo>
<GenerateDocumentationFile>true</GenerateDocumentationFile>
<NoWarn>$(NoWarn);1591</NoWarn>
</PropertyGroup>
</Project>
But when I build this project, I get this messageTarget "UpdateAssemblyInfo" skipped, due to false condition; ($(UpdateAssemblyInfo) == 'true') was evaluated as (false == 'true').
And thisProperty reassignment: $(UpdateAssemblyInfo)="false" (previous value: "true") at \.nuget\packages\gitversiontask\5.3.4\build\GitVersionTask.props (22,9)
and the version is "0.0.0.0"
In version 5.0.1 it works fine and write current version of file.
Also, if I insert “<UpdateAssemblyInfo>true</UpdateAssemblyInfo>” into the project itself, version calculation and writing is successful.
Properties
directory. The command-line version does a recursive look. My AssemblyInfo.cs is currently at the root of the netstandard project. How can I verify that the MSBuild GitVersionTask
is working correctly?
-output json
(by default I think gitversion runs with -output buildserver
when running on azure).
$ git clone https://github.com/owner/repo.git owner/repo
Cloning into 'owner/repo'...
$ cd owner/repo
$ git fetch origin +refs/pull/33/merge:
From https://github.com/owner/repo
* branch refs/pull/33/merge -> FETCH_HEAD
$ git checkout -qf FETCH_HEAD
It looks like the branch being examined is a detached Head pointing to commit '4786479'. Without a proper branch name GitVersion cannot determine the build version.