Gitversion using date as major version in devops build

Question

I have a couple of webapps I am adding gitversion to. Main problem - GitVersion is generating a MajorMinorPatchTag where the Major is in the format yyyymmdd. Aside from this not being a valid major version, I want the usual versioning 0.1.3.alpha.1 in the example below but I am getting 20201021.1.1.

I have removed all the old build tags from the repo so it does not appear to be finding this from tags. Is there anywhere else I can force it to ignore previous build versions and use the semver starting from the gitversion.yml/next-version setting?

Detail below:

The gitversion.yml is simple:

assembly-versioning-scheme: MajorMinorPatchTag
mode: Mainline 
next-version: 0.1.3 
increment: Inherit
branches:
 feature:
   tag: alpha
 master:
   tag: 
ignore:
 sha: []

The DevOps build task has

Gitversion

steps:
- task: gittools.usegitversion.gitversion-task.UseGitVersion@5
  displayName: GitVersion
  inputs:
    versionSpec: 5.x

Build

steps:
- task: DotNetCoreCLI@2
  displayName: Build
  inputs:
    projects: '$(Parameters.RestoreBuildProjects)'
    arguments: '--configuration $(BuildConfiguration) /p:Version=$(GitVersion.SemVer)

'

The output of the gitversion task is as follows:

Installing GitVersion.Tool version 5.x
-------------------------- 
Found tool in cache: GitVersion.Tool 5.3.7 x64
Prepending PATH environment variable with directory: C:\DevOps\_work\_tool\GitVersion.Tool\5.3.7\x64
C:\DevOps\_work\_tool\GitVersion.Tool\5.3.7\x64\dotnet-gitversion.exe C:/DevOps/_work/31/s /output buildserver /nofetch
INFO [10/21/20 20:51:49:55] Working directory: C:/DevOps/_work/31/s
INFO [10/21/20 20:51:49:57] Branch from build environment: refs/heads/master
INFO [10/21/20 20:51:49:57] Project root is: C:\DevOps\_work\31\s\
INFO [10/21/20 20:51:49:57] DotGit directory is: C:\DevOps\_work\31\s\.git
INFO [10/21/20 20:51:49:57] Begin: Normalizing git directory for branch 'refs/heads/master'
INFO [10/21/20 20:51:49:61] One remote found (origin -> 'https://example.com/asfalis/Legacy/_git/example.WebApi.exampleWebhookHandler').
INFO [10/21/20 20:51:49:61] Skipping fetching, if GitVersion does not calculate your version as expected you might need to allow fetching or use dynamic repositories
INFO [10/21/20 20:51:49:61] Updating local branch refs/heads/master to point at 0311e72378d5187490b39eddbfff243643b952c1
INFO [10/21/20 20:51:49:65] HEAD points at branch 'refs/heads/master'.
INFO [10/21/20 20:51:49:65] End: Normalizing git directory for branch 'refs/heads/master' (Took: 78.57ms)
INFO [10/21/20 20:51:49:67] Begin: Loading version variables from disk cache
INFO [10/21/20 20:51:49:67] Begin: Deserializing version variables from cache file C:\DevOps\_work\31\s\.git\gitversion_cache\59EC1078831A476936644C50EA5AB6347D5E7CD7.yml
INFO [10/21/20 20:51:49:73] End: Deserializing version variables from cache file C:\DevOps\_work\31\s\.git\gitversion_cache\59EC1078831A476936644C50EA5AB6347D5E7CD7.yml (Took: 61.06ms)
INFO [10/21/20 20:51:49:73] End: Loading version variables from disk cache (Took: 63.28ms)
INFO [10/21/20 20:51:49:75] Using latest commit on specified branch
Executing GenerateSetVersionMessage for 'AzurePipelines'.
Executing GenerateBuildLogOutput for 'AzurePipelines'.
INFO [10/21/20 20:51:49:79] Done writing 
Async Command Start: Update Build Number
Update build number to 20200619.1.1+1 for build 441
Async Command End: Update Build Number
Finishing: GitVersion

with an error in the build as

....AssemblyInfo.cs(19,55): Error CS7034: The specified version string does not conform to the required format - major[.minor[.build[.revision]]]

Update 1

After moving to GitTools bundle, this is the output from "Establish Version" task:

C:\DevOps\_work\_tool\GitVersion.Tool\5.1.3\x64\dotnet-gitversion.exe C:/DevOps/_work/31/s /output json /output buildserver
{
  "Major":20200619,
  "Minor":1,
  "Patch":1,
  "PreReleaseTag":"",
  "PreReleaseTagWithDash":"",
  "PreReleaseLabel":"",
  "PreReleaseNumber":"",
  "WeightedPreReleaseNumber":"",
  "BuildMetaData":1,
  "BuildMetaDataPadded":"0001",
  "FullBuildMetaData":"1.Branch.master.Sha.0311e72378d5187490b39eddbfff243643b952c1",
  "MajorMinorPatch":"20200619.1.1",
  "SemVer":"20200619.1.1",
  "LegacySemVer":"20200619.1.1",
  "LegacySemVerPadded":"20200619.1.1",
  "AssemblySemVer":"20200619.1.1.0",
  "AssemblySemFileVer":"20200619.1.1.0",
  "FullSemVer":"20200619.1.1+1",
  "InformationalVersion":"20200619.1.1+1.Branch.master.Sha.0311e72378d5187490b39eddbfff243643b952c1",
  "BranchName":"master",
  "Sha":"0311e72378d5187490b39eddbfff243643b952c1",
  "ShortSha":"0311e72",
  "NuGetVersionV2":"20200619.1.1",
  "NuGetVersion":"20200619.1.1",
  "NuGetPreReleaseTagV2":"",
  "NuGetPreReleaseTag":"",
  "VersionSourceSha":"e40a0b671680c65428fe13610ee4cca25eefeaac",
  "CommitsSinceVersionSource":1,
  "CommitsSinceVersionSourcePadded":"0001",
  "CommitDate":"2020-10-21"
}

Krzysztof Madej · Accepted Answer · 2020-10-21 22:42:13Z

2

GitTools.UseGitVersion is deprected thus I recommend you switch to GitTools bundle and then you can use it like this:

steps:
- task: gitversion/setup@0
  enabled: true
  displayName: Install GitVersion
  inputs:
    versionSpec: '5.1.3'

- task: gitversion/execute@0
  enabled: true
  displayName: 'Establish Version'

- powershell: Write-Host "##vso[build.updatebuildnumber]$(FullSemVer)"
  displayName: 'Update build number to $(FullSemVer)'

and then you can try

- task: DotNetCoreCLI@2
  displayName: Build
  inputs:
    projects: '$(Parameters.RestoreBuildProjects)'
    arguments: '--configuration $(BuildConfiguration) /p:Version=$(FullSemVer)

Please check this link

  steps:
  - task: gitversion/setup@0
    displayName: Install GitVersion
    inputs:
      versionSpec: '5.1.3'
  - task: gitversion/execute@0
    displayName: Use GitVersion
  - script: |
      echo FullSemVer: $(fullSemVer)
      echo ##vso[build.updatebuildnumber]$(fullSemVer)
      echo Major: ${{ steps.gitversion.outputs.major }}
      echo Minor: ${{ steps.gitversion.outputs.minor }}
      echo Patch: ${{ steps.gitversion.outputs.patch }}
      echo PreReleaseTag: ${{ steps.gitversion.outputs.preReleaseTag }}
      echo PreReleaseTagWithDash: ${{ steps.gitversion.outputs.preReleaseTagWithDash }}
      echo PreReleaseLabel: ${{ steps.gitversion.outputs.preReleaseLabel }}
      echo PreReleaseNumber: ${{ steps.gitversion.outputs.preReleaseNumber }}
      echo WeightedPreReleaseNumber: ${{ steps.gitversion.outputs.weightedPreReleaseNumber }}
      echo BuildMetaData: ${{ steps.gitversion.outputs.buildMetaData }}
      echo BuildMetaDataPadded: ${{ steps.gitversion.outputs.buildMetaDataPadded }}
      echo FullBuildMetaData: ${{ steps.gitversion.outputs.fullBuildMetaData }}
      echo MajorMinorPatch: ${{ steps.gitversion.outputs.majorMinorPatch }}
      echo SemVer: ${{ steps.gitversion.outputs.semVer }}
      echo LegacySemVer: ${{ steps.gitversion.outputs.legacySemVer }}
      echo LegacySemVerPadded: ${{ steps.gitversion.outputs.legacySemVerPadded }}
      echo AssemblySemVer: ${{ steps.gitversion.outputs.assemblySemVer }}
      echo AssemblySemFileVer: ${{ steps.gitversion.outputs.assemblySemFileVer }}
      echo InformationalVersion: ${{ steps.gitversion.outputs.informationalVersion }}
      echo BranchName: ${{ steps.gitversion.outputs.branchName }}
      echo Sha: ${{ steps.gitversion.outputs.sha }}
      echo ShortSha: ${{ steps.gitversion.outputs.shortSha }}
      echo NuGetVersionV2: ${{ steps.gitversion.outputs.nuGetVersionV2 }}
      echo NuGetVersion: ${{ steps.gitversion.outputs.nuGetVersion }}
      echo NuGetPreReleaseTagV2: ${{ steps.gitversion.outputs.nuGetPreReleaseTagV2 }}
      echo NuGetPreReleaseTag: ${{ steps.gitversion.outputs.nuGetPreReleaseTag }}
      echo VersionSourceSha: ${{ steps.gitversion.outputs.versionSourceSha }}
      echo CommitsSinceVersionSource: ${{ steps.gitversion.outputs.commitsSinceVersionSource }}
      echo CommitsSinceVersionSourcePadded: ${{ steps.gitversion.outputs.commitsSinceVersionSourcePadded }}
      echo CommitDate: ${{ steps.gitversion.outputs.commitDate }}

Maybe as workaround you will be able to use these to combine them into SemVer:

      echo Major: ${{ steps.gitversion.outputs.major }}
      echo Minor: ${{ steps.gitversion.outputs.minor }}
      echo Patch: ${{ steps.gitversion.outputs.patch }}

Looking here I think that it can be caused by your list release. Can you verify it? If this is true please make a release with me expected schema versioning and then try again run your build.

edited Oct 21, 2020 at 22:42

answered Oct 21, 2020 at 20:33

Krzysztof Madej

42.1k10 gold badges117 silver badges141 bronze badges

Sign up to request clarification or add additional context in comments.

9 Comments

MarkD Over a year ago

thanks. Good to use the updated package. It is still setting a date though (e.g. "FullSemVer":"20200619.1.1+1",). The problem may be that earlier check-in/commit or build on master before I started using using GitVersion are somehow tagged with a date and overriding the next-version setting.

Krzysztof Madej Over a year ago

Can you add - script: env | sort after Update build number and share the result with us to see how other values are set? Or maybe it would be better if you use this: github.com/GitTools/actions/blob/master/docs/examples/azure/… to show variables

MarkD Over a year ago

thanks - see edit/update 1 for the output of the Establish Version task. I remember before when I first tried this, I had to check in 3 or 4 tagged versions and then GitVersion would forget the old commits in the calculation. Hopefully that may give a clue.

Krzysztof Madej Over a year ago

And what about tags in git. Can you show what you have for git tag?

MarkD Over a year ago

ok, fixed it by a lucky guess. It looks like old tags are not removed in local repos. The fix was to do a "Clean" / "All Build Directories" in the Get Sources section of the pipeline. the clue was looking at my local machine - it too was not removing old tags. Thanks for your help above - using the new bundle and the debug has helped.

|

MarkD · Accepted Answer · 2020-10-23 17:38:35Z

thanks Krzysztof Madej for helping with this.

Turns out the "problem" is with Git in that it does not automatically prune tags in local repos. ("problem" is not really a bug - there are good reasons for not pruning local tags).

So when using our self hosted build server, the old tags (yyyymmdd.1.1) were hanging around on the agent from a prior build even after I deleted those tags on the server. Because yyyymmdd is greater than the semver major I wanted, it was used instead. Downstream, the build complained of an invalid major version.

If you are using MS Hosted agents, you get a clean git repo every time so no old tags, no problems.

If using self-hosted agents, workaround - set the clean option on the pipeline sources.

For local builds, issue a "git fetch origin --prune --prune-tags" (not tested but I got a clue from this post.)

Collectives™ on Stack Overflow

Gitversion using date as major version in devops build

2 Answers 2

9 Comments

Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

9 Comments

Comments

Your Answer

Sign up or log in

Post as a guest

Related