You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
trigger:
branches:
include:
- main
- feature*pool:
vmImage: windows-latestvariables:
buildConfiguration: 'Release'steps:
# The following task does not exist in case GitVersion.MsBuild is used
- task: gitversion/setup@0displayName: 'Set up GitVersion'inputs:
versionSpec: '5.x'# The following task does not exist in case GitVersion.MsBuild is used
- task: gitversion/execute@0displayName: 'Execute GitVersion'inputs:
useConfigFile: trueconfigFilePath: 'GitVersion.yml'additionalArguments: '/updateprojectfiles'
- task: DotNetCoreCLI@2displayName: 'Build $(buildConfiguration) configuration'inputs:
command: 'build'arguments: '-c $(buildConfiguration)'
- task: DotNetCoreCLI@2displayName: 'Pack NuGet packages'inputs:
command: 'custom'custom: 'pack'arguments: '--no-build -c $(buildConfiguration) -o $(Build.ArtifactStagingDirectory)'
- task: PublishPipelineArtifact@1inputs:
targetPath: '$(Build.ArtifactStagingDirectory)'artifactType: 'pipeline'artifactName: 'drop'
Let's now assume we run the above pipeline (with the two tasks) on the main branch and the FullSemVer and NuGetVersion values reported by the gitversion/execute@0 task are 2.1.3+3 and 2.1.3, respectively. The following version tag can then be found in the .nuspec file contained in the NuGet package:
<version>2.1.3</version>
The above version 2.1.3 is exactly what I would expect. However, if I use the GitVersion.MsBuild NuGet package in the next pipeline run (without the two tasks), the corresponding version tag would be as follows:
<version>2.1.3+4</version>
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 the VSBuild@1 task in another pipeline.
Expected Behavior
Using GitVersion.MsBuild, the NuGet package version is in the format 2.1.3 and identical to what gitversion/execute@0 would produce.
Actual Behavior
Using GitVersion.MsBuild, the NuGet package version is in the format 2.1.3+4 and different from what gitversion/execute@0 would produce.
Possible Fix
Unfortunately, I don't have a fix.
Steps to Reproduce
Create a super-simple SDK-style C# project (I'm targeting net50 in mine) with a single class and the above GitVersion.yml and azure-pipelines.yml.
Run the pipeline and check the version value in the .nuspec file contained in the NuGet package produced by the pipeline run.
Install the GitVersion.MsBuild NuGet package and uncomment the two gitversion tasks in azure-pipelines.yml.
Run the pipeline again and check the version value in the .nuspec file contained in the NuGet package.
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 the gitversion.tool is the way to go (as it also updates the build number, which GitVersion.MsBuild does not do).
Your Environment
Visual Studio 2019 on Windows 10
Azure DevOps with Azure Repo and Azure Pipelines
Option 1: GitVersion.MsBuild version 5.8.1
Option 2: gitversion.tool version 5.8.1
The text was updated successfully, but these errors were encountered:
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.
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.1The text was updated successfully, but these errors were encountered: