GitVersion with Azure DevOps Pipeline Releases

[NArnott]

I am trying to create a very basic pipeline for a nuget package using .NET and azure pipelines. I'm having trouble understanding how to set up my build and release in Azure DevOps.

The build works well enough using GitVersionTask. However, until the commit is tagged, I end up with some pre-release tag added to my assemblies and nuget package. That pre-release version is what's added as a Build artifact. When It's time to execute a release against that build, I'm not sure how to get a release version of the nuget package for pushing to my nuget repo.

I understand that I have to tag the commit in order to increment the version number, but as the build has already happened, tagging after the fact doesn't do anything. Short of tagging, and then re-building as part of the release, I'm not sure how to get this set up properly.

I hope I'm making sense here. It's been a few years since using git in general, and have been using DevOps with TFS since then.

[Antebios]

So, let me get this straight: You have a pre-release artifact "SomeArtifact-1.2.3-ci-4.nupkg". And now you are ready to release it. You want to tag it with "git tag v1.2.3" and the artifact will become "SomeArtifact-1.2.3.nupkg"? Correct? AH! I re-read your post, and I think I understand that the Azure Build Definition is not creating the build artifact after you tag it?

Setting this up:
I) Creating your Git repo: You should already have done this. I won't go over this.
II) Creating your Build Pipeline (build definition). You have this and should have the a trigger configured to automatically build when code is checked in AND when a git tag is applied and PUSHED up.

1. Go into the build definition and then go to Triggers
2. Enable the checkbox for "Enable continuous integration"
3. Under branch filters add an entry and set "type" ==> "include" and "branch specification" ==> "*"
4. add another entry for branch filters and set "type" ==> "include" and "branch specification" ==> "refs/tags/v*"
   WHY? Since you are using GitVersion, we want to build ALL branches that are created, including feature branches that come up in the future, so now you no longer need to modify this build definition. It is set and forget. Second, this build definition will not detect a trigger is pushed and do a build unless it is explicitly told to detect it,, so we need to tell it to listen to any tag that starts with a lower case 'v' and anything after it. Now when you create a git tag and push it to the central git repo your build is automatically start to build.
5. Save your changes.

III) Creating your Release Pipeline - This is a more complex explanation that involves "connecting" the Release (aka deployment) definition to the Build Pipeline that was created just above and telling the Release Pipeline to "listen" to BOTH the "master" branch AND "refs/tags/v" again when defining the artifact, and then I add a filter at the Production environment part to filter "refs/tags/v" again. Why? I want everything (pre-release and final release artifacts to go to lower environments, but only release artifacts to go to Production. If the artifact doesn't contain a git tag that starts with a lower-case 'v' then the pipeline ends and doesn't proceed. It is a safety-net.)

Here are instructions on constructing the Release Pipeline:

1. Go to Release Pipelines and click to create a new Release Pipeline
2. I start with an Empty Job.
3. I set the name of "Stage name" to "Dev Env" for this purpose.
4. Click on the blue "+Add" in the "Artifacts" area to add a new Artifact.
5. "Source Type" defaults to "Build" which is what we want, and "Project" defaults to your project.
6. Now select your Build Pipeline from above
7. For "Default version" I set it to "Latest from a specific branch with tags" because I want to always get it from the master branch, but you can set it to whatever you prefer.
8. Branch, I set it to "master", but this is going to be dependent on what your answer was on number 7 previously.
9. Set Source alias to anything you want, I set mine to "_Artifact".
10. Click on the blue "Add" button. You are done with this part. Now to the next.

1. While still dealing with the artifact, click on the "lightning bolt" in the upper-right corner of the artifact object.
2. The top slider for "Continuous deployment trigger" is disabled, and needs to be enabled. Click to enable.
3. For "Build branch filters" click the "Add" button and add the "master" branch.
4. Click the "Add" button again and type in "refs/tags/v*" and hit enter.
5. Now click the "X" in the upper-right corner of this panel. You are done with this part.
6. Save your Release Pipeline with what we have so far so we don't lose what you've done so far.

Now from this part going forward you are going to have to click inside the "Stages" area and see a component for "Dev Env" that we created earlier. You need to customize that for your needs. You do that under the "Tasks" menu. You will eventually add more "Stages". If you want to prevent pre-release artifacts (aka non-tagged) from getting through into that particular environment you do this:

1. Click on the Environment Stage PRE-DEPLOYMENT CONDITION icon (it looks like a Lightning Bolt with a person underneath it).
2. A side-panel appears that says "Pre-deployment conditions. and then the first section is "Triggers".
3. Withing that section is "Artifact filters" which should be disabled right now. We want to enable that IF we want to prevent pre-release artifacts from getting in.
4. For "Artifacts filters" click the slider to enable the filter.
5. Click the blue "+Add" button.
6. Select "_Artifacts" or whatever alias you used.
7. Type should be "Include" and for "Build branch" enter in "refs/tags/v*" and hit enter.
8. SAVE your work.

Why do I filter tags with "v*"? So just in case you want to use a tag its intended purpose as a labeling tool to marking something important or any other purpose. You might want to tag it "this is some awesome code". But we can reserve "vThis is awesome code" or "v1.0.0" for releases. I hope this helps and clarifies how the pipelines "connect" and how GitVersion fits in all this to make life better.

[biohazard999]

@Antebios <3 thank you. That is awesome, I didn't know that branch filtering is also working on tags!

[fernandobaba]

Hi, I saw this post and thought it's similar enough to what I'm experiencing.

I have the GitVersion task and here's what I'm trying to achieve:

master branch: 1.x.x
release branch: 1.x.x-beta.x
develop branch: 2.x.x-alpha.x
feature branch: 2.x.x.x-alpha.x

Currently, my GitVersion.yml

branches:
  develop:
    regex: dev(elop)?(ment)?$
    mode: ContinuousDelivery
    tag: alpha
  feature:
    regex: features?[/-]
    mode: ContinuousDelivery
    tag: alpha.{BranchName}
  release:
    regex: releases?[/-]
    mode: ContinuousDelivery
    tag: beta
  hotfix:
    regex: hotfix(es)?[/-]
    mode: ContinuousDelivery
    tag: beta
  master:
    mode: ContinuousDeployment

my build pipeline

trigger:
  batch: true
  branches:
    include:
      - master
      - develop
      - release/*

pool:
  name: 'build-host-lum'

steps:
  - task: GitVersion@4
    inputs:
      updateAssemblyInfo: true
      updateAssemblyInfoFilename: '**/AssemblyInfo.cs'

 ... omitted for brevity

When I create a release/2.4.3 branch, I'm actually getting 2.4.3.PullRequest324.17 as the version. I can't pinpoint what I'm doing wrong on the setup.

Any thoughts?

Apologies if this is the wrong place to post my question :)

[Antebios]

I'm sorry that I'm late, but when you type the command:
gitversion /showconfig see what configuration is being used.

Then rename "GitVersion.yaml" to "GitVersion.yml"

Then type gitversion /showconfig and see the difference of the configuration that is being used.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.