[Bug] GitVersion.MsBuild does not set Azure DevOps build number

[dagophil]

Hello,

I have a C# project that uses the GitVersionTask package. The project is built in an Azure DevOps pipeline. When running the build, the Azure DevOps build number is automatically set to the "FullSemVer". However, after upgrading GitVersionTask to GitVersion.MsBuild, the build number is not set anymore.

Expected Behavior

GitVersion.MsBuild should set the Azure DevOps build number.

Actual Behavior

GitVersion.MsBuild does not set the Azure DevOps build number.

Additional Information

The log shows the following line:

Executing GenerateBuildLogOutput for 'AzurePipelines'.

However, it does not show this line:

Executing GenerateSetVersionMessage for 'AzurePipelines'.

From the git version code (src/GitVersionCore/Core/BuildAgentBase.cs), this indicates that the updateBuildNumber variable is false:

if (updateBuildNumber)
{
    writer($"Executing GenerateSetVersionMessage for '{GetType().Name}'.");
    writer(GenerateSetVersionMessage(variables));
}
writer($"Executing GenerateBuildLogOutput for '{GetType().Name}'.");

I tried adding a GitVersion.yml with update-build-number: true, however, it did not help.

Your Environment

• Azure DevOps pipeline.
• Repository does not contain GitVersion.yml. If I run gitversion /showconfig locally, update-build-number is set to true.
• GitVersion.MsBuild 5.6.4

[ddprince-pro]

Hi,

I found this bug report while looking for this exact problem. We have just switched from GitVersionTask to GitVersion.MsBuild and we have the same issue.

Thanks,
David

[KiLLeRRaT]

We're in the same boat too

[HaGGi13]

Hi,

we have the same issue, after switching from GitVersionTask to GitVersion.MSBuild.
In my researches I found, that overwriting the BUILD_NUMBER variable is a bad behavior and was implemented in the past for TFS/Azure DevOps only, here the discussion #1457.
This behavior was fixed with PR #1770.

Now, I tried to update the Build number format string by replacing it with $(GITVERSION_FullSemVer), but after solution's built it was not replaced by GitVersion. So, only the mentioned variable name is displayed.

Are there any suggestions or approaches how to set the build definition's build number during/after a build with the GitVersion.MSBuild NuGet package installed in project solution only, without using Azure DevOps Server extension? The company I'm working for will avoid to install ADO Server extensions for compatibility reasons.

Thanks in advance and looking forward for replies or an updated documentation about this topic.

[paulcustance-al]

Having a similar issue with GitVersion.MsBuild not setting the build number correctly in Azure Devops. While for me it is outputting the environment variables and I can use them in tasks such as NuGet packing, it isn't setting the build number correctly on the pipeline.

I was having a dig round the code base and found this:

GitVersion/src/GitVersion.MsBuild/GitVersionTaskExecutor.cs

Lines 66 to 70 in 0cfa014

	public void WriteVersionInfoToBuildLog(WriteVersionInfoToBuildLog task)
	{
	versionVariables = VersionVariables.FromFile(task.VersionFile, fileSystem, log);
	gitVersionOutputTool.OutputVariables(versionVariables, false);
	}

The false on line 69 is the parameter for updating the build number and is always set to false. At this point in the code there is an options class from GitVersionOptions, but i couldn't see anything there that would allow to check if updateBuildNumber had been set. I was struggling to find how the GitVersionContext (which has the updateBuildNumber flag) is turned into GitVersionOptions.

The false value set above for updateBuildNumber is then passed down to the agent writer here:

GitVersion/src/GitVersion.Core/Core/BuildAgentBase.cs

Lines 38 to 42 in 0cfa014

	if (updateBuildNumber)
	{
	writer($"Executing GenerateSetVersionMessage for '{GetType().Name}'.");
	writer(GenerateSetVersionMessage(variables));
	}

As it is false it never gets written out to the agent. I can do some more digging but any pointers on how GitVersionContext becomes GitVersionOptions would be helpful or or if there is a flag already in GitVersionOptions for updateBuildNumber. Then I can test setting the hardcoded false value to something that comes from configuration and see if this solves the issue.

[ThomasPiskol]

Fixing this issue is not easy. During the investigation of #2592 I've found out, that the setting update-build-number is currently hard-coded to false in GitVersion.MsBuild.

I've intended to simply read the actual configuration from the GitVersion.yml file, but unfortunately this does not work for GitVersion.MsBuild.

Root cause is, that for finding that IConfigProvider.Provide uses internally LibGit2Sharp which has a dependency to the native implementation of libgit2.

For .NET Framework 4.8 this is not an issue, but unfortunately for .NET Core 3.1 and .NET 5. As of today, MsBuild does not support custom tasks which have a native dependency for .NET Core. This is an known issue, but not fixed yet.

Previously the workaround for this issue was implemented in the PR #2221.

I'm not sure if it's intended to apply the same workaround again for GitVersion.MsBuild. By doing so, GitVersion.MsBuild would again have a dependency to LibGit2Sharp which was removed earlier by just using internally the dotnet tool deployment of GitVersion.

Another possible solution could be to change the implementation of the ConfigProvider to not use LibGit2Sharp for reading GitVersions own config file. From a first look it seems that some effort is required, it's not just a simple task.

A third option would be to introduce a new MsBuild property for update-build-number like the existing UpdateAssemblyInfo. This seems like a bad idea, because it's not obvious for the users of GitVersion why the setting in GitVersion.yml is ignored for GitVersion.MsBuild.

[sevenate]

Hi,

I found this bug report while looking for this exact problem. We have just switched from GitVersionTask to GitVersion.MsBuild and we have the same issue.

Thanks,
David

What are the benefits of switching from GitVersionTask to new GitVersion.MsBuild then? I'm hesitating between using old one where this pipeline build number update is working and a new GitVersion.MsBuild where this is broken as of now (and supposed to be fixed eventually, but no guarantee when)

[KiLLeRRaT]

Hi,
I found this bug report while looking for this exact problem. We have just switched from GitVersionTask to GitVersion.MsBuild and we have the same issue.
Thanks,
David

What are the benefits of switching from GitVersionTask to new GitVersion.MsBuild then? I'm hesitating between using old one where this pipeline build number update is working and a new GitVersion.MsBuild where this is broken as of now (and supposed to be fixed eventually, but no guarantee when)

I have this same issue and question.

Currently my team are all using the GitVersionTask for .NET Framework, and for .NET Core projects and works adequately.

Cheers,

[arturcic]

The reason is GitVersionTask is obsolete and no improvements/ fixes will be made. GitVersion.MsBuild is different in the way it is packaged and adds support for more platforms including Ubuntu 20.04, and is the maintainable package

[sevenate]

The reason is GitVersionTask is obsolete and no improvements/ fixes will be made. GitVersion.MsBuild is different in the way it is packaged and adds support for more platforms including Ubuntu 20.04, and is the maintainable package

Thanks, that is good to know, but realistically for Windows builds - does it really matter? Is there anything GitVersion.MsBuild is doing that GitVersionTask can't?

[arturcic]

At this moment no, it behaves similarly, but later when we'll release v6 it will be different

[sevenate]

Here is a workaround that could be used until the GitVersion.MsBuild will be able to do it on its own:

# Updating pipeline build number to actual semantic version
- script: echo %Action%%BuildVersion%
  displayName: 'Updating build # to SemVer'
  env:
    Action: '##vso[build.updatebuildnumber]'
    BuildVersion: '$(GitVersion.FullSemVer)'

Should be placed in *.yml pipeline file (right) after the solution/project with GitVersion.MsBuild package build task.

Source