Open ThomasBarnekow opened 2 years ago
If GitVersion.Tool
gives you the version number you want, why do you want to use GitVersion.MSBuild
? You can try to configure the MSBuild task. Setting UseFullSemVerForNuGet
to false
should yield a version number without the build metadata (+4
).
@asbjornu, I had been using the GitVersionTask
for quite some time. When you deprecated it, the natural move was to use GitVersion.MsBuild
. This, however, did not yield the expected results. Therefore, I tried the GitVersion.Tool
, which did produce the expected results. This is somewhat puzzling.
Since the difference between those two options might not be what you guys intended, I filed an issue.
I see @ThomasBarnekow. I agree the behaviour should be consistent. If you find the inspiration to submit a pull request to fix this, please do.
Thanks, @asbjornu, I will unfortunately not have the time to do this. However, I hope that my detailed description of the issue is still helpful.
Description
Trying to find a way to produce NuGet packages with Azure pipelines in a Continuous Delivery mode, I tested different approaches:
gitversion.tool
with thegitversion/setup@0
andgitversion/execute@0
tasks inazure-pipelines.yml
vs.GitVersion.MsBuild
without the above two tasks inazure-pipelines.yml
.In both cases, version 5.8.1 is used with the following
GitVersion.yml
file:The
azure-pipelines.yml
file looks like this:Let's now assume we run the above pipeline (with the two tasks) on the
main
branch and theFullSemVer
andNuGetVersion
values reported by thegitversion/execute@0
task are2.1.3+3
and2.1.3
, respectively. The following version tag can then be found in the.nuspec
file contained in the NuGet package:The above version
2.1.3
is exactly what I would expect. However, if I use theGitVersion.MsBuild
NuGet package in the next pipeline run (without the two tasks), the corresponding version tag would be as follows:The issue here is that this is (a) not what I would expect and (b) different from what I get when using
gitversion/execute@0
.As a side note (and potentially additional issue or bug), when using the
DotNetCoreCLI@2
task to build the solution or project, I do not have access to the GitVersion variables e.g.,$(GitVersion.FullSemVer)
or$(GitVersion.NuGetVersion)
. If I remember correctly, I did have access to those variables when using theVSBuild@1
task in another pipeline.Expected Behavior
Using
GitVersion.MsBuild
, the NuGet package version is in the format2.1.3
and identical to whatgitversion/execute@0
would produce.Actual Behavior
Using
GitVersion.MsBuild
, the NuGet package version is in the format2.1.3+4
and different from whatgitversion/execute@0
would produce.Possible Fix
Unfortunately, I don't have a fix.
Steps to Reproduce
net50
in mine) with a single class and the aboveGitVersion.yml
andazure-pipelines.yml
.GitVersion.MsBuild
NuGet package and uncomment the twogitversion
tasks inazure-pipelines.yml
.Context
As I said above, I am trying to produce NuGet packages in a Continuous Delivery mode. I've spent a ton of time trying to find out how to make this work, because
GitVersion.MsBuild
does not produce the expected NuGet package versions. It seems that thegitversion.tool
is the way to go (as it also updates the build number, whichGitVersion.MsBuild
does not do).Your Environment
GitVersion.MsBuild
version 5.8.1gitversion.tool
version 5.8.1