TFS 2015. the $(var.SourceLocation) variable is not available at gated-check in

0
votes

We are migrating from old XAML build definition to new TFS 2015 build. In old we have gated-check in that is working fine. In new one we have such option on "Triggers" tab. However I want use commit ID that trigger build. The variable $(Build.SourceVersion) is responsible for this, but for gated-check in it is not being set. It looks right, because commit was not accepted by TFS yet.

The question is how to grab this commit ID either during gated-check in or following CI ?

Should I create just another build for gated check-in that just compile our solution and only if succeeded will trigger CI ?

2
azure-devopstfsbuildtfs-2015
What are you trying to do with the commit ID? I don't understand what the problem is. You shouldn't need the commit ID unless you're trying to do something like pass it to a script. – Daniel Mann
I need commit id to generate special folder name and put on server. like "dev_build_c6445_20170120.1". – Alezis
@Alezis, Do you mean gated check-in trigger or CI trigger? Git team project doesn't support gated check-in trigger in TFS 2015.Or you want to say changeset ID instead of commit ID? – Cece Dong - MSFT
My goal to replicate old XAML builds. We would like have just gated check-in. In addition we need to inject exact changeset id into drop folder on a server. this changeset can help us find correct sources the build was createdfrom.we use TFS as source control version. – Alezis

2 Answers

1
votes

There is no way to get the changeset id that hasn't checked in during gated check-in. Please check the screenshot below, checking in gated changes is in the very last step in the build process, which can't be controlled. After the build completes, the variable $(Build.SourceVersion) will update automatically. So we are not able to get the changeset id that hasn't checked in until the build completes.

enter image description here

You would need to use TFS REST API to get the build that has completed, then fetch the "sourceVersion":

GET http://{instance}/DefaultCollection/{project}/_apis/build/builds/{buildId}?api-version={version}
0
votes

So far, I end up with not clean workaround, but it were accepted by our management. I created two build definitions: one for gated-check in, one for CI. Once someone checked in something gated check-in fires. If it completed successfully, CI build would be triggered. Please note corresponding checkbox on UI:

gated CI

This is not so clean solution, but it works for me.