5

I am setting our build/release environment using TFS 2017.

I set up the Build to run automatically after each commit, and when we are ready to release a version of our application, a Release is manually created, and then deployed to various environments.

We would like to tag released versions in our git repository in order to easily know which git revision correspond to a binary. The "Label Source" setting in the Build definition allows to tag a git revision at build time, but since we build on every commit that would generate a lot of tags which we don't care about (as they are not deployed anywhere until a release is made).

How can TFS be setup so that when a Release is created (or possibly, deployed to an environment), a tag is created on the corresponding commit in our Git repository?

ndeslandes
  • 195
  • 1
  • 13

3 Answers3

4

You can add tags by using REST API:

POST https://{instance}/DefaultCollection/_apis/git/repositories/{repository}/refs?api-version={version}

[
  {
    "name": {string},
    "oldObjectId": {string}, (The current commit id the ref is at. 0000000000000000000000000000000000000000 when creating a new ref.)
    "newObjectId": {string}
  }
]

Calling Rest API through PowerShell:

$result = Invoke-RestMethod -Uri $uri -Method Get -ContentType "application/json" -Headers @{Authorization=("Basic {0}" -f $base64AuthInfo)}

More information, you can refer to Calling VSTS APIs with PowerShell (apply to tfs 2017)

starian chen-MSFT
  • 33,174
  • 2
  • 29
  • 53
  • 1
    Brilliant! That's exactly what I needed. The commit ref is available in the release in the `$(BUILD.SOURCEVERSION)` variable, so I can assign the new tag to that revision. Here's the PS command that I used: `Invoke-RestMethod $uri -Method Post -Body (ConvertTo-Json $body) -Credential $cred -ContentType "application/json"` And the `name` property in the body should be set to something like: `"refs/tags/v_0.9.234.2"` – ndeslandes Mar 24 '17 at 11:58
  • Thanks for the helping info. I would add a link to the relevant documentation page: https://learn.microsoft.com/en-us/previous-versions/azure/devops/integrate/previous-apis/git/refs?view=azure-devops – Alberto Chiesa Nov 27 '21 at 09:46
3

I have built a vsts extension that does exactly this: https://marketplace.visualstudio.com/items?itemName=jabbera.git-tag-on-release-task

Mike Barry
  • 953
  • 5
  • 15
1

You can add a command line task in your release definition and use git command git tag -a vx.x $(Build.SourceVersion) -m "xxx" to add a tag, check the screenshot below:

enter image description here

=========================================================================

Update:

In order to avoid specifying the working folder where the git reop checked out, you can publish the $(build.sourcesdirectory) to drop folder in build definition, then in release definition, you can simply select the drop folder directory. Check the screenshots below:

enter image description here

enter image description here

Cece Dong - MSFT
  • 29,631
  • 1
  • 24
  • 39
  • 1
    Thanks a lot for the suggestion. But this only works if you know where to find a directory on the agent that contains a checkout of the git repository (C:\TFS2015Agent\agent\_work\4\s in your example). What if the release happens on a different build agent? Or worse, what if somehow another repository was clone in the location where the git tag is executed. You might end up tagging the wrong repo! – ndeslandes Mar 20 '17 at 16:43
  • 1
    Well, I supposed that would work... But it seems incredibly wasteful to package up the entire source directory as an artifact on every build just to add a tag to the repository! Imagine if the repo was 1 GB! Not to mention that that would include also the entire Git history, so you could be looking at multiple GB for a large repo. – ndeslandes Mar 23 '17 at 11:01
  • Instead of publishing the sources folder, why not simply specify `$(Build.Repository.LocalPath)`as the working folder? – JamesQMurphy May 26 '18 at 01:25
  • In a release, the source hasn't been checked out, and `$(Build.Repository.LocalPath)` and `$(Build.SourcesDirectory)` aren't populated. I think the REST API is probably a better steer. – Jaykul Jul 18 '18 at 03:32