Update Version Variables And Package

The UpdateVersionVariablesAndPackage VSTS task updates the variables that are used to name the artifact and is used to perform replacements in the application.

This task is used to perform autoversioning of artifacts and application versions.

It is recommended to use Git Flow.

Important

Git: Only Tested with Azure DevOps git.

Agent Specification: Tested on Windows and Linux.

Documentation

To create an upgrade version, pipeline variables are used:

Major, Minor and Patch

As a summary, the final version is also stored in the variable:

VersionTag and VersionJava

Configure the tasks in YAML

  - task: solucionespsg.UpdateVersionVariablesAndPackage.psg.UpdateVersionVariablesAndPackage.UpdateVersionVariablesAndPackage@1
    displayName: 'Update Version Variables And Package'
	inputs:
		UpdateBuildNumber: Yes
		TagBranch: release
		BuildSourceBranchName: '$(Build.SourceBranchName)'
		BuildSourceVersion: '$(Build.SourceVersion)'

    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)

Configure the tasks in YAML with Templates:

jobs:
- job: Versioning
  pool: ${{ parameters.pool }}
  variables:
    sourceBranch: $[ resources.repositories['${{parameters.codeRepo}}'].ref ]
	versionCommit: $[ resources.repositories['${{parameters.codeRepo}}'].version ]
  steps:
  - checkout: "${{ parameters.codeRepo }}"
    displayName: "Checkout"
    persistCredentials: true
  - task: solucionespsg.UpdateVersionVariablesAndPackage.psg.UpdateVersionVariablesAndPackage.UpdateVersionVariablesAndPackage@1
    displayName: 'Update Version Variables And Package'
	inputs:
		UpdateBuildNumber: Yes
		TagBranch: release
		BuildSourceBranchName: '$(sourceBranch)'
		BuildSourceVersion: '$(versionCommit)'
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)

Pre configure the tasks for classic editor

Configure Allow scripts to access the OAuth token:

Security:

Find the user running the pipeline:

First we must enter the "Name of your project" and then Build Service

For example: "Project1 Build Service"

Set "Edit build pipeline" in "Allow"

This is so that the user running the pipeline can update the value of the variables. This must be repeated for each pipeline.

Or simply add the user "Name of your project Build Service" to the project Contributors group. So you don't have to give permission on each and every pipe. (Recommended option)

Other option is: add the user "Name of your project Build Service" in Organization Group: "Project Collection Build Administrators"

With these last options, it is only done once and it is not necessary to then grant permissions in each pipeline.

Logic for versioning v 0.*:

Deprecated logic. The patch was increased instead of the minor

Logic for versioning v 1.*:

When a git push is made to the branch, the following procedure is performed:

If the git push has a tag in "x.y.z" format

The variables are updated: Major, Minor and Patch with the values "x", "y" and "z"

If the git push does not have a tag

• If the branch is "master" or "main" and does not come from a hotfix branch

  is updated first: Minor = Minor + 1

  Patch=0

  HotFixCounter = 0

  ReleaseCounter = 0

  Version = Major + Minor + Patch

  VersionJava = Major + Minor + Patch

• If the branch is "master" or "main" and come from a hotfix branch

  Is updated first: Patch = Patch + 1

  Version = Major + Minor + Patch

  VersionJava = Major + Minor + Patch

  Important

  To tell if it's coming from a hotfix branch, it grab the commit comment. By default, in git, when performing a merge, the comment is something like "Merge branch 'hotfix/*'". This works perfect. Now, if a PullRequest is made from Azure devOps, this comment is not added automatically, so the following must be added to the comment: ..."hotfix/*"... For example: "Merge from hotfix/bug-01 is resolves productive error"

  If it is another git repository and the merge or pull request does not add the automatic comment, the following must be added to the comment: ..."hotfix/*"... or ..."Merged PR *"... For example: "Merge from hotfix /bug-01 resolves productive error"

• If the branch is "develop" or "bugfix/*"

  Version = Major + Minor + Patch +"-yyyyMMdd-HHmmss"

  VersionJava = Major + Minor + Patch + "-SNAPSHOT"

• If the branch is "release/*"

  The Minor variable is not updated in the pipeline. But we add one because it is the value it will have when the merge is done to master

  Is updated ReleaseCounter = ReleaseCounter + 1

  Version = Major + (Minor+1) + Patch + "-RC-" + ReleaseCounter

  VersionJava = Major + (Minor+1) + Patch + "-RC-" + ReleaseCounter

• If the branch is "feature/*"

  Version = Major + Minor + Patch +"-yyyyMMdd-HHmmss"

  Version = Major + Minor + Patch + "-LOCAL"

• If the branch is "hotfix/*"

  The Patch variable is not updated in the pipeline. But we add one because it is the value it will have when the merge is done to master

  Is updated HotFixCounter = HotFixCounter + 1

  Version = Major + Minor + (Patch+1) + "-HRC-" + HotFixCounter

  VersionJava = Major + Minor + (Patch+1) + "-HRC-" + HotFixCounter

• Other branch name

  Version = Major + Minor + Patch +"-yyyyMMdd-HHmmss"

  VersionJava = Major + Minor + Patch + "-SNAPSHOT"

Example graphs using git flow

Feature

Bugfix

Release

Hotfix

Variables that we can use after finishing the task:

Version: example output: "1.2.6-20231502-010322"

VersionJava: example output: "1.2.6-SNAPSHOT"

VersionShort: example output: "1.2.6"

NewMajor: example output: "1"

NewMinor: example output: "2"

NewPatch: example output: "6"

Extra variables:

To perform overrides in .net frameworks projects:

Assembly: example output: "[assembly: AssemblyVersion("1.2.6")]"

AssemblyFile: example output: "[assembly: AssemblyFileVersion("1.2.6")]"

Output variables

VersionOut: example output: "1.2.6-20231502-010322"

VersionJavaOut: example output: "1.2.6-SNAPSHOT"

VersionShortOut: example output: "1.2.6"

NewMajorOut: example output: "1"

NewMinorOut: example output: "2"

NewPatchOut: example output: "6"

Extra variables:

To perform overrides in .net frameworks projects:

AssemblyOut: example output: "[assembly: AssemblyVersion("1.2.6")]"

AssemblyFileOut: example output: "[assembly: AssemblyFileVersion("1.2.6")]"

For use in yaml with templates:

Example:

-template: mytemplate.yml@templates
    parameters:
        Version: $[dependencies.Job_1.outputs['solucionespsg.UpdateVersionVariablesAndPackage.psg.UpdateVersionVariablesAndPackage.UpdateVersionVariablesAndPackage@1.VersionOut']]
        targetFilesReplace: "**/*.json;**/*.js"

examples to replace variables:

For .Net Framework projects

We use the Replace Tokens task. Before build the solution:

replace these values with the value of variable Assembly and AssemblyFile

To version your nuget packages

To replace version in azure DevOps custom task project

These are some examples among the thousands of uses that the autoversioning of our projects has.

Help to continue development.

If it helped you. You can help me:

https:// paypal.me/solucionespsg