Use convention to derive a SemVer product version from a GitFlow based repository
arturcic on 5.3.6
Is there a way to make gitversion
ignore commit messages and only use tags for versions?
I have a repo that uses gitflow but we have these non-semver "marketing" version numbers that are YYYY.N
(year and number of releases that year). So we had some big effort on some release that had the release branch named something like release/2020.5-giant-project
so there were merge messages with that into master
and back into develop
etc. The actual version is 2.0.0
and there's an annotated tag on master
but gitversion seems to ignore that tag and insists that the new version for develop
should be some 2020.6.0
stuff, but it shouldn't, it should probably be 2.1.0
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.