Tfs add build tag update#
Tfs add build tag software#
Tfs add build tag code#

echo '#vso$(major).$(minor)-$(Build.SourceBranchName).$(brpatch)' condition: ne(variables, 'PullRequest')

This function will only run when the build.reason is not equal to Pull Request.

Tfs add build tag update#

In a similar way, we will use build.sourcebranchname as prefix and start our seed value with 0, so for each run of the pipeline, the value of variable brpatch will increment as 0,1,2… variables: brpatch: $, 0)]Īs the next step, we will use Azure DevOps’s build.updatebuildnumber function to update the version of the running pipeline. If we change the minor variable value to 2, the seed value resets to 0 as the prefix has changed. Each run of the pipeline will increment its seed value. Below, the seed value starts with 0, and the prefix value is variable minor i.e 1. If the branch is not master, it declares a variable called brpatch which uses a counter expression.Ĭounter expression in Azure DevOps: A counter expression increments the seed value based on its prefix value. condition: ne(variables, 'refs/heads/master') Also, we have declared major and minor variables to 2 and 0. We have created a stage called Build_Branch_Version_Number, in which we have declared a condition that allows this stage to be run only if the branch is not master. trigger: - master pool: vmImage: 'ubuntu-latest' variables: major: 2 minor: 0 stages: - stage: displayName: Build_Branch_Version_Number condition: ne(variables, 'refs/heads/master') jobs: - job: Build_Branch_Version_Number variables: brpatch: $, 0)] steps: - bash: | echo '#vso$(major).$(minor)-$(Build.SourceBranchName).$(brpatch)' condition: ne(variables, 'PullRequest') name: SetBranchBuildName - stage: Build_Steps displayName: Build_Steps jobs: - job: Build_Steps displayName: Build_Steps steps: - script: echo Hello, world! name: 'Run_a_one_line_script' - script: | echo Add other tasks to build, test, and deploy your project. In this branch, we will add the below lines to the azure-pipelines.yml file so that our feature branch is versioned differently. Let’s start by creating a new feature branch from master, let’s call it feature_branch_changes.

Tfs add build tag software#

Again, a lot of this depends on your branching strategy, this is just a versioning example of the common flow of software development. So we have to define a versioning system for these builds.

Tfs add build tag code#

echo See displayName: 'Run a multi-line script'Ĭustom Version Build Building and versioning PR builds and feature branchesĪs developers start working on feature branches and raise PR’s to merge into the main branch, we need to make sure the code quality is maintained by the code review process and successful PR builds. trigger: - master pool: vmImage: 'ubuntu-latest' steps: - script: echo Hello, world! displayName: 'Run a one-line script' - script: | echo Add other tasks to build, test, and deploy your project.

1 and subsequent builds will be incremented as 20191207. Tools like Gitversion and Minver also help achieve semantic versioning.īefore we dig into the main topic, some introduction to Azure DevOps pipelines.īy default, Azure DevOps will version your build with YYYYMMDD.Revision format.įor example, if we build the below azure-pipelines.yml file, the first build number will be 20191207. The idea is to version the master branch differently than PR and feature branch builds. The first will be versioning PR and feature branch builds, and the second will be versioning a master branch. We will cover this article in two iterations. The scope of this article is restricted to application builds and versioning using Azure Pipelines YAML file.