[Bug] Build number in Azure DevOps wrong

[KiLLeRRaT]

Describe the bug
The build number in Azure DevOps has changed and most likely not respecting my GitVersion.yml file anymore.

Expected Behavior

The build number should be 2.4.0-beta.24 when building off a tag called 2.4.0-beta.24.

Actual Behavior

The build number is set to 2.4.0-tags-2-4-0-beta-24.1 when building off of the tag 2.4.0-beta.24

Possible Fix

This seems to have been introduced in 5.12.0. If I revert back to 5.11.x, it works as it should. Could this somehow be related to the prerelease tag changes that were made? Is it because I don't have a beta tag against the master branch in my config but I'm specifying it in a tag or something?

Here is the compare between the two versions for reference: 5.11.1...5.12.0

Context

this is making a mess of my NuGet packages, as they are all now submitted with the weird version.

Your Environment

• Version Used: 5.12.0
• Operating System and version (Windows 10, Ubuntu 18.04): Azure DevOps, agent vmImage: 'windows-latest', .NET 6.0

My GitVersion.yml file:

assembly-versioning-scheme: Major
assembly-informational-format: '{Major}.{Minor}.{Patch}{PreReleaseTagWithDash}+{CommitsSinceVersionSource}.Branch.{EscapedBranchName}.Sha.{ShortSha}'
mode: ContinuousDelivery
increment: Inherit
#tag-prefix: '[vV]'
branches:
    master:
        regex: ^master
        mode: ContinuousDelivery
        tag: ''
        increment: Patch
        prevent-increment-of-merged-branch-version: true
        track-merge-target: false
        tracks-release-branches: false
        is-release-branch: true
    release:
        regex: ^releases?[/-]
        mode: ContinuousDelivery
        tag: beta
        increment: Patch
        prevent-increment-of-merged-branch-version: true
        track-merge-target: false
        tracks-release-branches: false
        is-release-branch: true
    feature:
        regex: ^features?[/-]
        mode: ContinuousDeployment
        tag: alpha
        increment: Minor
        prevent-increment-of-merged-branch-version: false
        track-merge-target: false
        tracks-release-branches: false
        is-release-branch: false

[asbjornu]

Seems like this is related to #2074, #2301, #2838, #2852, #3104 and probably more, which should have been fixed in #3033. In particular, #3033 (comment) may be of interest. I don't think @ThomasPiskol managed to automate testing of that, so perhaps we've somehow reverted his fixes somehow?

[ausarb]

@asbjornu - I can confirm that we had this problem with 5.12.0 (5.x as of this comment) where our master is tagged as 3.0.0 but NuGetVersionV2 is 3.0.1-tags-3-0-0-0001. When I updated our GitHub Actions step to specifically use 5.10.0, the tag build produced a NuGetVersionV2 of 3.0.0 as desired.

[KiLLeRRaT]

Any ideas on how to get around this one guys? Or is it going to have to be another fix?

Thanks!

[JDCain]

I am seeing this issue as well. Anything built off of a tag adds the -tags---*- into the prerelease tag

[HHobeck]

May I ask you to create an integration test (like in Figure 1) to reproduce your issue?

Figure 1: Example of an Integration Test

[KiLLeRRaT]

I will give this a shot, but I may not get around to it in a few weeks :( sorry!

[HHobeck]

I'm going to close this issue because of missing steps to reproduce. Please try your scenario on the preview version 6.0.0-beta.1 which reflects the latest develop initiaitves and give me feedback if your issue still persists. Thank you very much.

[fbernack]

I'm facing the same issue using version 5.12.x and also using 6.0.0-beta.1. Reverting to 5.11.x solved it for me.

[HHobeck]

I'm facing the same issue using version 5.12.x and also using 6.0.0-beta.1. Reverting to 5.11.x solved it for me.

Please provide steps to reproduce for the 6.x version. Thank you

[KiLLeRRaT]

Hi @HHobeck,

I've finally gotten around to making a test file.

I hope we can re-open this issue and get the core team to look into it for us.

The test file I came up with is the following:

TagCheckoutInBuildAgentTests2.cs

using GitTools.Testing;
using GitVersion.BuildAgents;
using GitVersion.Core.Tests.Helpers;
using LibGit2Sharp;
using NUnit.Framework;
using Shouldly;

namespace GitVersion.App.Tests;

[TestFixture]
public class TagCheckoutInBuildAgentTests2
{
    [Test]
    public async Task VerifyTagCheckoutOnAzurePipelines2()
    {
        var env = new Dictionary<string, string>
        {
            { AzurePipelines.EnvironmentVariableName, "true" },
            { "BUILD_SOURCEBRANCH", "refs/tags/0.2.0-beta.1" }
        };

        await VerifyTagCheckoutVersionIsCalculatedProperly2(env);
    }


    private static async Task VerifyTagCheckoutVersionIsCalculatedProperly2(Dictionary<string, string> env)
    {
        using var fixture = new EmptyRepositoryFixture("main");
        var remoteRepositoryPath = ExecutableHelper.GetTempPath();
        RepositoryFixtureBase.Init(remoteRepositoryPath, "main");
        using (var remoteRepository = new Repository(remoteRepositoryPath))
        {
            remoteRepository.Config.Set("user.name", "Test");
            remoteRepository.Config.Set("user.email", "[email protected]");
            fixture.Repository.Network.Remotes.Add("origin", remoteRepositoryPath);
            Console.WriteLine("Created git repository at {0}", remoteRepositoryPath);
            remoteRepository.MakeATaggedCommit("0.2.0-beta.1");

            Commands.Fetch((Repository)fixture.Repository, "origin", Array.Empty<string>(), new FetchOptions(), null);
            Commands.Checkout(fixture.Repository, "0.2.0-beta.1");
        }

        var programFixture = new ProgramFixture(fixture.RepositoryPath);
        programFixture.WithEnv(env.ToArray());

        var result = await programFixture.Run();

        result.ExitCode.ShouldBe(0);
        result.OutputVariables.ShouldNotBeNull();
        result.OutputVariables.SemVer.ShouldBe("0.2.0-beta.1");

        // Cleanup repository files
        DirectoryHelper.DeleteDirectory(remoteRepositoryPath);
    }

}

I have run a git bisect between the 5.11.1 and 5.12.0, and it looks like the first bad commit is:

3a6b12348aeac7b5ae459e83b71e6d1e74ea23c2 is the first bad commit
commit 3a6b12348aeac7b5ae459e83b71e6d1e74ea23c2
Author: Enrique Raso <[email protected]>
Date:   Thu Oct 6 12:50:19 2022 +0200

    Add unit tests in SupportBranchScenarios

 .../IntegrationTests/SupportBranchScenarios.cs     | 27 ++++++++++++++++++++++
 .../VersionCalculation/NextVersionCalculator.cs    |  6 +++++
 2 files changed, 33 insertions(+)

Looking at NextVersionCalculator.cs, this is the change that breaks it:

diff --git a/src/GitVersion.Core/VersionCalculation/NextVersionCalculator.cs b/src/GitVersion.Core/VersionCalculation/NextVersionCalculator.cs
index 32320acc8..7103ef1c0 100644
--- a/src/GitVersion.Core/VersionCalculation/NextVersionCalculator.cs
+++ b/src/GitVersion.Core/VersionCalculation/NextVersionCalculator.cs
@@ -97,6 +97,12 @@ public NextVersion FindVersion()
            {
                // set the commit count on the tagged ver
                taggedSemanticVersion.BuildMetaData.CommitsSinceVersionSource = semver.BuildMetaData?.CommitsSinceVersionSource;

                {+// set the updated prerelease tag when it doesn't match with prerelease tag defined in branch configuration+}
{+                if (preReleaseTagDoesNotMatchConfiguration)+}
{+                {+}
{+                    taggedSemanticVersion.PreReleaseTag = semver.PreReleaseTag;+}
{+                }+}
            }
        }

If I remove that portion, it works as it used to before.

I hope this helps sort out the issue at hand!

Let me know if you need more information please.

Regards,
Albert

[KiLLeRRaT]

Sorry, but tagging in @enriqueraso as he was the committer, and may miss this issue since he's not a full time contributor.

@enriqueraso , could you please explain this part of the code, and what cases it's meant to solve?

Thanks,

[enriqueraso]

Hi, you will find more detail in these PRs

#3224

#3181

[enriqueraso]

If you revert the change that I introduced this bug will appear again. #3223

I have releases branch configured with '' empty tag and defined as mainline, and main branch as '-rc' tag and also as mainline. Feature and bug branches are created from releases branch and they increase Minor or Patch when merging in releases branch. Main branch is used to create a new releases branch.

[HHobeck]

Hi there.

Your scenario seems to me not common and maybe your workflow is not properly configured. You have a main branch with a pre-release label empty and tag it with a beta label and expecting that GitVersion detects it. Please have a look to the following tests:

GitVersion/src/GitVersion.Core.Tests/IntegrationTests/OtherScenarios.cs

Line 258 in 0ff62cc

public void EnsurePreReleaseTagLabelWithInitialTagForPatchNumberOneWillBeConsideredIfNoLabelIsDefined()

In the integration test you define this:

var env = new Dictionary<string, string>
{
    { AzurePipelines.EnvironmentVariableName, "true" },
    { "BUILD_SOURCEBRANCH", "refs/tags/0.2.0-beta.1" }
};

which results in:

What I'm supprised is that in your scenario the current branch is tags/0.2.0-beta.1. Thus the resulting calculation of the version 0.2.0-tags-0-2-0-beta-1.1 is fully correct because of the unknown branch feature. In your scenario the pre-release label will be effectively {BranchName} (see https://github.com/GitTools/GitVersion/blob/main/src/GitVersion.Configuration/SupportedWorkflows/GitFlow/v1.yml#L104C6-L104C6).

To change the behavior you need to either:

• define a branch configuration with name tags with no label (with ContinuousDelivery mode) or
• define a branch configuration with name tags with label beta or
• change the main branch configuration an set to no label (with ContinuousDelivery mode) or
• change the main branch configuration an set to label beta or
• use another branch which matches the pre-release label beta

Good to know: If you don't care about what the pre-release label might be you need to specify the label on branch and on root level to null.

Edit: I have used the 6.0.0-beta.3 version of GitVersion.

[KiLLeRRaT]

Hi @HHobeck, thanks for your thorough explanation. I will have a shot at these suggestions and let you know if I 'm still stuck.

Regards,

[HHobeck]

Hi @KiLLeRRaT .

Yes please try it out. Maybe you need to go two steps back and change your workflow or at least change the configuration. To specify every time the BUILD_SOURCEBRANCH environment variable seems to be not so ideal. But I can't say anything about your workflow itself because I don't know it and I have no information about your motivation. ;) Let me know if you have success.

Regards

[HHobeck]

I think it is related to:

• [Bug] 5.12.0 does not respect tag in Continuous Deployment mode #3614

[KiLLeRRaT]

Hi @KiLLeRRaT .

Yes please try it out. Maybe you need to go two steps back and change your workflow or at least change the configuration. To specify every time the BUILD_SOURCEBRANCH environment variable seems to be not so ideal. But I can't say anything about your workflow itself because I don't know it and I have no information about your motivation. ;) Let me know if you have success.

Regards

I'll briefly explain our workflow, which I thought was quite simple:

For all our internal frameworks, we have a master branch. We don't use or need the automatic versioning. When we want to version a commit, we tag that commit, and run the CICD pipeline. We then expect the DLLs and so on to be that version.

If we want to release a beta version, we'd tag the commit in master with 2.0.0-beta.1 and if it builds, it should be that version. If we then want to release 2.0.0 we just tag the commit that's going to be 2.0.0 and run the pipeline again.

We have had this workflow for many years, and it's been working well for us.

Do you have any config recommendations for us to achieve that?

Here is an example config of one of our libraries:

assembly-versioning-scheme: Major
assembly-informational-format: '{Major}.{Minor}.{Patch}{PreReleaseTagWithDash}+{CommitsSinceVersionSource}.Branch.{EscapedBranchName}.Sha.{ShortSha}'
branches:
  master:
    regex: ^master$|^main$
    mode: ContinuousDelivery
    tag: ''
    increment: Patch
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
    tracks-release-branches: false
    is-release-branch: false

Thank you for your time!

Regards,

[HHobeck]

What about this (with 6.00-beta.3 version)?

assembly-versioning-scheme: Major
assembly-informational-format: '{Major}.{Minor}.{Patch}{PreReleaseTagWithDash}+{CommitsSinceVersionSource}.Branch.{EscapedBranchName}.Sha.{ShortSha}'
branches:
  tags:
    mode: ContinuousDelivery
    label:
    increment: None
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
    regex: ^tags[/-]
    source-branches:
    - develop
    - main
    - release
    - feature
    - pull-request
    - hotfix
    - support
    tracks-release-branches: false
    is-release-branch: false
    is-mainline: false
    pre-release-weight: 0
ignore:
  sha: []
label:

Edit: Maybe you can skip the source-branches and some other properties:

assembly-versioning-scheme: Major
assembly-informational-format: '{Major}.{Minor}.{Patch}{PreReleaseTagWithDash}+{CommitsSinceVersionSource}.Branch.{EscapedBranchName}.Sha.{ShortSha}'
branches:
  tags:
    mode: ContinuousDelivery
    label:
    regex: ^tags[/-]
ignore:
  sha: []
label:

[KiLLeRRaT]

Hi @HHobeck
I've tried that, no luck unfortunately.

5.11.1

Here is my run on 5.11.1:

This is the config:

assembly-versioning-scheme: Major
assembly-informational-format: '{Major}.{Minor}.{Patch}{PreReleaseTagWithDash}+{CommitsSinceVersionSource}.Branch.{EscapedBranchName}.Sha.{ShortSha}'
mode: ContinuousDelivery
increment: Inherit
branches:
    master:
        regex: ^master
        mode: ContinuousDelivery
        increment: Patch
        prevent-increment-of-merged-branch-version: true
        track-merge-target: false
        tracks-release-branches: false
        is-release-branch: true

6.0.0-beta.4

Config (your last minimal version, I've also tried your full config version suggestion):

assembly-versioning-scheme: Major
assembly-informational-format: '{Major}.{Minor}.{Patch}{PreReleaseTagWithDash}+{CommitsSinceVersionSource}.Branch.{EscapedBranchName}.Sha.{ShortSha}'
branches:
  tags:
    mode: ContinuousDelivery
    label:
    regex: ^tags[/-]
ignore:
  sha: []
label:

This is the git log:

Heh all I want is the version to be exactly what the tag is, 4.0.0-beta.3.

I have tried my old working config with 6.0.0-beta.4 too, also no luck.

Thanks for you help with this in advance.

[JDCain]

I have this problem as well and have also reverted to 5.11.1.

It only seems to happen during the build on the DevOps agent because it doesn't actually clone the branch of say master when a build triggers based on a tag, it instead downloads the tag via refs/tags/{tagname}.

I'm not sure how to do this locally in order to try and replicate it.

[HHobeck]

Heh all I want is the version to be exactly what the tag is, 4.0.0-beta.3.

I have tried my old working config with 6.0.0-beta.4 too, also no luck.

Thanks for you help with this in advance.

Actually it is quite better then the initial behaviour right!? ;) I'm not sure if your test scenario is the same like on the azure devops pipeline because the BUILD_SOURCEBRANCH environment variable is properly not defined with refs/tags/4.0.0-beta.3. Anyway it seems you are executing the command on a main branch and there the comparision between the new and old version is lacking.

Can you mabe try this:

assembly-versioning-scheme: Major
assembly-informational-format: '{Major}.{Minor}.{Patch}{PreReleaseTagWithDash}+{CommitsSinceVersionSource}.Branch.{EscapedBranchName}.Sha.{ShortSha}'
branches:
  main:
    label:
  tags:
    mode: ContinuousDelivery
    label:
    regex: ^tags[/-]
ignore:
  sha: []
label:

[KiLLeRRaT]

I have tried the config you've posted:

assembly-versioning-scheme: Major
assembly-informational-format: '{Major}.{Minor}.{Patch}{PreReleaseTagWithDash}+{CommitsSinceVersionSource}.Branch.{EscapedBranchName}.Sha.{ShortSha}'
branches:
  main:
    label:
  tags:
    mode: ContinuousDelivery
    label:
    regex: ^tags[/-]
ignore:
  sha: []
label:

I tried it on master with the tag 4.0.0-beta.8 and that produced:

I have also tried checking out the tag directly, and that produced:

In Azure DevOps I run it against the tag directly, not on the master branch. On my machine, the same behaviour is happening when running it against master directly. When switching between 5.11.1 and any later version, the problem still comes up.

Do you know if there is there a way to force it to only look at the latest tag and perhaps counting the commits since that tag?

Thanks :)

[HHobeck]

It is very difficult for me to help you because I have no inside into your repository.

I have tried it with beta.4 on azure devops and it is working:

next-version: 1.0.0
mode: ContinuousDeployment
branches:
  main:
    mode: ContinuousDelivery
    label:
  tags:
    mode: ContinuousDelivery
    label:
    regex: ^tags[/-]
  feature:
    mode: ContinuousDeployment
    increment: Minor
  hotfix:
    mode: ContinuousDeployment
    increment: Patch
ignore:
  sha: []
merge-message-formats: {}
label:

[HHobeck]

Your first execution:
This can't be. Please check:

• the correct configuration will be used for master
• the tag is on the current commit existing

Edit: Please try git fetch origin -pP. I think the tag is missing locally in your workspace. ;)

Your Second execution:
Because you are in the detached head you need to say GitVersion for what branch he needs to determine the version. In your case it would be refs/tags/4.0.0-beta.4 (via environment variable BUILD_SOURCEBRANCH and TF_BUILD with value true) to have it like in azure devops.

[KiLLeRRaT]

It is very difficult for me to help you because I have no inside into your repository.

I have tried it with beta.4 on azure devops and it is working:

next-version: 1.0.0
mode: ContinuousDeployment
branches:
branches:
  main:
    mode: ContinuousDelivery
    label:
  tags:
    mode: ContinuousDelivery
    label:
    regex: ^tags[/-]
  feature:
    mode: ContinuousDeployment
    increment: Minor
  hotfix:
    mode: ContinuousDeployment
    increment: Patch
ignore:
  sha: []
merge-message-formats: {}
label:

Is this on a public repo? If so I could take a look and compare it to my structure :) Please let me know.

[HHobeck]

Nope it's not public

[KiLLeRRaT]

Righto, I have some sort of success :)

Using the config you last posted (I removed a couple of things):

assembly-versioning-scheme: Major
assembly-informational-format: '{Major}.{Minor}.{Patch}{PreReleaseTagWithDash}+{CommitsSinceVersionSource}.Branch.{EscapedBranchName}.Sha.{ShortSha}'
mode: ContinuousDeployment
branches:
  main:
    mode: ContinuousDelivery
    label:
  tags:
    mode: ContinuousDelivery
    label:
    regex: ^tags[/-]
ignore:
  sha: []
label:

I get expected results:

I think it was because we didn't have the mode: ContinuousDelivery on the main branch config.

I then tried it via the nuget package, but got a build error, so I will stay on 6.0.0-beta.3 for the moment. More info below on that.

I just want to say thanks a lot of helping out with this, and I can understand that it's very tricky because of everybody's repos being different and private etc.

6.0.0-beta.4 Build Error when referencing via Nuget

I think unrelated, and probably needs a separate issue created.

When I try to build using a nuget reference to 6.0.0-beta.4 I get a build error, so I went back to 6.0.0-beta.3. Not quite sure that that's about, but below is what happens.

Currently running Linux, .NET 8.

MSBuild version 17.8.3+195e7f5a3 for .NET
  Determining projects to restore...
  All projects are up-to-date for restore.
  Could not execute because the specified command or file was not found.
  Possible reasons for this include:
    * You misspelled a built-in dotnet command.
    * You intended to execute a .NET program, but dotnet---roll-forward does not exist.
    * You intended to run a global tool, but a dotnet-prefixed executable with this name could not be found on the PATH.
/home/albert/.nuget/packages/gitversion.msbuild/6.0.0-beta.4/tools/GitVersion.MsBuild.targets(18,9): error MSB3073: The command "dotnet --roll-forward Major "/home/albert/.nuget/packages/gitversion.msbuild/6.0.0-beta.4/tools//gitversion.dll" "/home/albert/source/SAL.Sandfield.Database.Migrator/src/Sandfield.Database.Migrator"  -output file -outputfile obj/gitversion.json" exited with code 1. [/home/albert/source/SAL.Sandfield.Database.Migrator/src/Sandfield.Database.Migrator/Sandfield.Database.Migrator.csproj]

Build FAILED.

/home/albert/.nuget/packages/gitversion.msbuild/6.0.0-beta.4/tools/GitVersion.MsBuild.targets(18,9): error MSB3073: The command "dotnet --roll-forward Major "/home/albert/.nuget/packages/gitversion.msbuild/6.0.0-beta.4/tools//gitversion.dll" "/home/albert/source/SAL.Sandfield.Database.Migrator/src/Sandfield.Database.Migrator"  -output file -outputfile obj/gitversion.json" exited with code 1. [/home/albert/source/SAL.Sandfield.Database.Migrator/src/Sandfield.Database.Migrator/Sandfield.Database.Migrator.csproj]
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:01.10

[HHobeck]

6.0.0-beta.4 Build Error when referencing via Nuget

I think unrelated, and probably needs a separate issue created.

When I try to build using a nuget reference to 6.0.0-beta.4 I get a build error, so I went back to 6.0.0-beta.3. Not quite sure that that's about, but below is what happens.

Currently running Linux, .NET 8.

MSBuild version 17.8.3+195e7f5a3 for .NET
  Determining projects to restore...
  All projects are up-to-date for restore.
  Could not execute because the specified command or file was not found.
  Possible reasons for this include:
    * You misspelled a built-in dotnet command.
    * You intended to execute a .NET program, but dotnet---roll-forward does not exist.
    * You intended to run a global tool, but a dotnet-prefixed executable with this name could not be found on the PATH.
/home/albert/.nuget/packages/gitversion.msbuild/6.0.0-beta.4/tools/GitVersion.MsBuild.targets(18,9): error MSB3073: The command "dotnet --roll-forward Major "/home/albert/.nuget/packages/gitversion.msbuild/6.0.0-beta.4/tools//gitversion.dll" "/home/albert/source/SAL.Sandfield.Database.Migrator/src/Sandfield.Database.Migrator"  -output file -outputfile obj/gitversion.json" exited with code 1. [/home/albert/source/SAL.Sandfield.Database.Migrator/src/Sandfield.Database.Migrator/Sandfield.Database.Migrator.csproj]

Build FAILED.

/home/albert/.nuget/packages/gitversion.msbuild/6.0.0-beta.4/tools/GitVersion.MsBuild.targets(18,9): error MSB3073: The command "dotnet --roll-forward Major "/home/albert/.nuget/packages/gitversion.msbuild/6.0.0-beta.4/tools//gitversion.dll" "/home/albert/source/SAL.Sandfield.Database.Migrator/src/Sandfield.Database.Migrator"  -output file -outputfile obj/gitversion.json" exited with code 1. [/home/albert/source/SAL.Sandfield.Database.Migrator/src/Sandfield.Database.Migrator/Sandfield.Database.Migrator.csproj]
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:01.10

Please try this version:

[KiLLeRRaT]

6.0.0-beta.4 Build Error when referencing via Nuget

I think unrelated, and probably needs a separate issue created.
When I try to build using a nuget reference to 6.0.0-beta.4 I get a build error, so I went back to 6.0.0-beta.3. Not quite sure that that's about, but below is what happens.
Currently running Linux, .NET 8.

MSBuild version 17.8.3+195e7f5a3 for .NET
  Determining projects to restore...
  All projects are up-to-date for restore.
  Could not execute because the specified command or file was not found.
  Possible reasons for this include:
    * You misspelled a built-in dotnet command.
    * You intended to execute a .NET program, but dotnet---roll-forward does not exist.
    * You intended to run a global tool, but a dotnet-prefixed executable with this name could not be found on the PATH.
/home/albert/.nuget/packages/gitversion.msbuild/6.0.0-beta.4/tools/GitVersion.MsBuild.targets(18,9): error MSB3073: The command "dotnet --roll-forward Major "/home/albert/.nuget/packages/gitversion.msbuild/6.0.0-beta.4/tools//gitversion.dll" "/home/albert/source/SAL.Sandfield.Database.Migrator/src/Sandfield.Database.Migrator"  -output file -outputfile obj/gitversion.json" exited with code 1. [/home/albert/source/SAL.Sandfield.Database.Migrator/src/Sandfield.Database.Migrator/Sandfield.Database.Migrator.csproj]

Build FAILED.

/home/albert/.nuget/packages/gitversion.msbuild/6.0.0-beta.4/tools/GitVersion.MsBuild.targets(18,9): error MSB3073: The command "dotnet --roll-forward Major "/home/albert/.nuget/packages/gitversion.msbuild/6.0.0-beta.4/tools//gitversion.dll" "/home/albert/source/SAL.Sandfield.Database.Migrator/src/Sandfield.Database.Migrator"  -output file -outputfile obj/gitversion.json" exited with code 1. [/home/albert/source/SAL.Sandfield.Database.Migrator/src/Sandfield.Database.Migrator/Sandfield.Database.Migrator.csproj]
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:01.10

Please try this version:

Nope.

dotnet build
MSBuild version 17.8.3+195e7f5a3 for .NET
  Determining projects to restore...
  All projects are up-to-date for restore.
  Could not execute because the specified command or file was not found.
  Possible reasons for this include:
    * You misspelled a built-in dotnet command.
    * You intended to execute a .NET program, but dotnet---roll-forward does not exist.
    * You intended to run a global tool, but a dotnet-prefixed executable with this name could not be found on the PATH.
/home/albert/.nuget/packages/gitversion.msbuild/6.0.0-beta.5/tools/GitVersion.MsBuild.targets(21,9): error MSB3073: The command "dotnet --roll-forward Major "/home/albert/.nuget/packages/gitversion.msbuild/6.0.0-beta.5/tools/netstandard2.0/gitversion.dll" "/home/albert/source/SAL.Sandfield.Database.Migrator/src/Sandfield.Database.Migrator"  -output file -outputfile obj/gitversion.json" exited with code 1. [/home/albert/source/SAL.Sandfield.Database.Migrator/src/Sandfield.Database.Migrator/Sandfield.Database.Migrator.csproj]

Build FAILED.

/home/albert/.nuget/packages/gitversion.msbuild/6.0.0-beta.5/tools/GitVersion.MsBuild.targets(21,9): error MSB3073: The command "dotnet --roll-forward Major "/home/albert/.nuget/packages/gitversion.msbuild/6.0.0-beta.5/tools/netstandard2.0/gitversion.dll" "/home/albert/source/SAL.Sandfield.Database.Migrator/src/Sandfield.Database.Migrator"  -output file -outputfile obj/gitversion.json" exited with code 1. [/home/albert/source/SAL.Sandfield.Database.Migrator/src/Sandfield.Database.Migrator/Sandfield.Database.Migrator.csproj]
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:01.10