[Bug] GitVersion.MsBuild does not set environment variables

[ThomasPiskol]

Describe the bug
GitVersion.MsBuild (5.6.6) does not create environment variables containing the version information calculated by GitVersion.
Maybe this is related to #2552

Expected Behavior

The following environment variables were present after building a .NET Standard 2.0 library project with dotnet build using GitVersionTask (5.5.1):

GitVersion_AssemblySemFileVer
GitVersion_AssemblySemVer
GitVersion_BranchName
GitVersion_CommitDate
GitVersion_CommitsSinceVersionSource
GitVersion_CommitsSinceVersionSourcePadded
GitVersion_EscapedBranchName
GitVersion_FullBuildMetaData
GitVersion_FullSemVer
GitVersion_InformationalVersion
GitVersion_LegacySemVer
GitVersion_LegacySemVerPadded
GitVersion_Major
GitVersion_MajorMinorPatch
GitVersion_Minor
GitVersion_NuGetVersion
GitVersion_NuGetVersionV2
GitVersion_Patch
GitVersion_PreReleaseTag
GitVersion_SemVer
GitVersion_Sha
GitVersion_ShortSha
GitVersion_UncommittedChanges
GitVersion_VersionSourceSha
GitVersion_WeightedPreReleaseNumber

Actual Behavior

No GitVersion_ environment variables are present when GitVersion.MsBuild (5.6.6) is used.

Steps to Reproduce

• create a .NET Standard 2.0 Library project and add GitVersion.MsBuild:

dotnet new classlib -f netstandard2.0
dotnet add package GitVersion.MsBuild --version 5.6.6

• setup GitHub Actions pipeline to build the project using dotnet build
• add a pipeline step to print all environment variables, e.g. via PowerShell:

Get-ChildItem env:* | Sort-Object Name | Format-Table -AutoSize | Out-String -Width 900

Context

The environment variables should be set also by GitVersion.MsBuild. It's quite common in a CI pipeline to use the calculated version for some other tasks.
In this case a GitHub release should be created using the SemVer as the name of the release and as the value for tag.

Your Environment

• GitHub Actions CI
• dotnet SDK 3.1.406

• Version Used: GitVersion.MsBuild (5.6.6)
• Operating System and version (Windows 10, Ubuntu 18.04): Ubuntu (18.04.5 LTS).
• Link to your project
• Link to your CI build (if appropriate):
  • Build using GitVersionTask 5.6.6
  • Build using GitVersion.MsBuild 5.5.1

[ThomasPiskol]

I think the root cause is this line in GitVersionTaskExecutor:

GitVersion/src/GitVersion.MsBuild/GitVersionTaskExecutor.cs

Line 69 in 80adc3f

gitVersionOutputTool.OutputVariables(versionVariables, false);

Previously in the old GitVersionTask the GitVersionTaskExecutor was not hard-coded to false for updateBuildVersion:

GitVersion/src/GitVersionTask/GitVersionTaskExecutor.cs

Line 60 in 26def75

gitVersionTool.OutputVariables(versionVariables);

It looks like the actual value was taken from versionContext.Value.Configuration.UpdateBuildNumber:

GitVersion/src/GitVersionCore/VersionConverters/OutputGenerator/OutputGenerator.cs

Line 35 in 26def75

buildAgent?.WriteIntegration(console.WriteLine, variables, versionContext.Value.Configuration.UpdateBuildNumber);

So in the new GitVersion.MsBuild the actual value of update-build-number is ignored and it is always set to false.
This should be ideally no problem in this case, but the GitHubActions implementation couples the creation of the GitVersion_* environment variables with the update-build-number setting:

if (writer == null || !updateBuildNumber)
{
    return;
}

From my point of view there are two issues:

1. Usage of updateBuildNumber in GitHubActions (responsible for this issue [Bug] GitVersion.MsBuild does not set environment variables #2592)
2. Hardcode value in GitVersionTaskExecutor (responsible for [Bug] GitVersion.MsBuild does not set Azure DevOps build number #2552)

Usage of updateBuildNumber in GitHubActions

I think skipping the creation of the GitVersion_* environment variables if updateBuildNumber is set to false is wrong, because the GitHubActions implementation does not change the build number at all. It just adds additional environment variables which should do no harm.
So I would like to change the check in GitHubActions to this:

if (writer == null)
{
    return;
}

Hardcode value in GitVersionTaskExecutor

It looks strange to me to use here a hard-coded value, but also the actual value is currently not available in GitVersionTaskExecutor because it uses GitVersionOptions and GitVersionOptions does not contain a value related to update-build-number.
I don't know why GitVersionOptions is used here instead of Config or EffectiveConfiguration.

What would be the right solution?

[asbjornu]

Thanks for the digging, @ThomasPiskol! Are you able to reproduce the problem in a test and able to submit it as a pull request?

[ThomasPiskol]

Yes, I'm able to reproduce it in a test case and I have a fix for the GitHubActions issue.
Probably I'm able to create a pull request next week.

But I'm not sure how to properly fix the hard coded value in GitVersionTaskExecutor.

My current idea is to make it similar like GitVersionExecutor in GitVersion.App: use IConfigProvider to get GitVersion.Model.Configuration.Config and then get the current value of update-build-number.

What do you think @asbjornu?

[arturcic]

I think we need to change to make it consistent with the app

[arturcic]

Related to #2592

[ThomasPiskol]

I have fixed #2592 but I'm stuck with the fix for #2552.
As discussed above I've changed GitVersionTaskExecutor so that it uses IConfigProvider to get the actual value of update-build-number:

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

            var configuration = configProvider.Provide(overrideConfig: options.Value.ConfigInfo.OverrideConfig);
            gitVersionOutputTool.OutputVariables(versionVariables, configuration.UpdateBuildNumber ?? false);
        }

In order to use IConfigProvider I had to add a reference to GitVersion.LibGit2Sharp, because IConfigProvider.Provide uses internally LibGit2Sharp to get the root folder of the repository.
This works in net48 but unfortunately neither in netcoreapp3.1 nor in net5.0. The reasons is that in both cases GitVersion.MsBuild.deps.json does not contain a reference to the location of the native libraries of libgit2. Instead it's just empty:

"LibGit2Sharp.NativeBinaries/2.0.312": {},

Due to this .NET Core expects the native libs to be present in the same folder like GitVersion.LibGit2Sharp.dll. I've verified this with Process Monitor:

But the libs are actually located in the runtimes folder which seems to be correct from my point of view.
Nevertheless, the native libs are not found and the call of IConfigProvider.Provide throws an System.TypeInitializationException ("The type initializer for 'LibGit2Sharp.Core.NativeMethods' threw an exception.")

This can be reproduces with NUnit tests and with manual tests by using a locally created NuGet package.

Previously in the old GitVersion.Task NuGet package (5.5.1) the GitVersionTask.deps.json contains the correct references that point to the native libs in the runtimes folder:

"LibGit2Sharp.NativeBinaries/2.0.298": {
        "runtimeTargets": {
          "runtimes/alpine-x64/native/libgit2-ef5a385.so": {
            "rid": "alpine-x64",
            "assetType": "native",
            "fileVersion": "0.0.0.0"
          },
...
          "runtimes/win-x64/native/git2-ef5a385.dll": {
            "rid": "win-x64",
            "assetType": "native",
            "fileVersion": "0.28.0.0"
          },
...
        }
      },

Currently I have no idea how to provide the correct path for the native libs.

[ThomasPiskol]

I've created a PR for this issue. Fixing the other issue #2552 is more complex. I'll discuss the possible solutions over there.

[arturcic]

🎉 This issue has been resolved in version 5.6.7 🎉
The release is available on:

• GitHub Release
• Chocolatey Package
• .Net Global Tool

Your GitReleaseManager bot 📦🚀