Determine how a TFS 2015 build was initiated from inside Msbuild

Question

Are there any properties etc. within MSBuild on TFS2015 (not XAML Builds) that will enable me to ascertain if the particular build was initiated manually or via a CI trigger?

I'm trying to avoid having two build definitions which differ only by a true/false value that is passed in as a property currently, e.g. with

/p:Manual=true

which I'm then using in my project as

$(Manual)

Without this, it looks like I need two definitions - one that's triggered via CI and passes as False in that property, the other manual that passes a True. If I had a means of finding out it the build was the result of a checkin then I could get away with needing two.

Edit 4/21/16

Just to clarify, I'm aware there's no property on the Build definition, I'm looking for something WITHIN the actual MSBuild process (as it's running) that would allow me to ascertain this.

At this point even getting the Login Id of the user who scheduled the build would do - if it's a triggered build my guess is that would be the Service account running TFS, otherwise it's a human.

Answer 1

To expand on Dhruv's answer, here is the relevant Powershell code to record the build reason for TFS 2015:

# Retrieve build reason via REST API call and set as TFS 'Build.BuildReason' variable
$url = "$($env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI)$env:SYSTEM_TEAMPROJECT/_apis/build/builds/$env:BUILD_BUILDNUMBER`?api-version=2.0"
$header = @{"Authorization" = "Bearer $env:SYSTEM_ACCESSTOKEN"}
$response = Invoke-RestMethod $url -Headers $header
$reason = $response.reason
Write-Host "##vso[task.setvariable variable=Build.BuildReason;]$reason"

Call it in a Powershell step before any steps that need to reference the build reason.

Answer 2

There are a couple of environment variables which are set by the build agent when a build is triggered. You can use these to figure out whether the build was requested by a user or the system identity and for whom the build was requested. From the docs:

 | Build.RequestedFor | BUILD_REQUESTEDFOR | This user the build was requested
 |                    |                    | for. In a CI build this will be
 |                    |                    | the user who performed the check-
 |                    |                    | in that triggered the build.
 ------------------------------------------------------------------------------
 | Build.QueuedBy     | BUILD_QUEUEDBY     | The identity of the user who 
 |                    |                    | queued the build. In the case 
 |                    |                    | of CI and Scheduled this will 
 |                    |                    | simply be the system identity
 |                    |                    | 
 |                    |                    | * For manual this will be the 
 |                    |                    |   identity of the user who queued
 |                    |                    |   the build
 |                    |                    | 
 |                    |                    | * For external triggers it will 
 |                    |                    |   be the identity used to 
 |                    |                    |   authenticate to the service
 ------------------------------------------------------------------------------
 | Build.SourceTfvcShelveset | BUILD_SOURCETFVCSHELVESET  | If you are 
 |                           |                            | running a gated 
 |                           |                            | build or a 
 |                           |                            | shelveset build 
 |                           |                            | Queue a build, 
 |                           |                            | this is set to 
 |                           |                            | the name of the 
 |                           |                            | shelveset you 
 |                           |                            | are building.
 ---------------------------------------------------------------------------

You can access these variables inside MsBuild, so Build.RequestedFor becomes $(BUILD_REQUESTEDFOR) inside your msbuild files.

It's not conclusive on whether the build was CI, Gates, Nightly or Batched, but it does distinguish Manually queued builds from triggered builds, which seems to be what you're after.

Answer 3

A way to automate this is running a powershell before msbuild in which you can use the rest api to get the reason of the current executing build as documented here.

Pass the return value of the rest api call to a variable and access the variable in msbuild.

There can be many other ways to automate this . This is being a way.

Answer 4

You can add to your vNext build a build variable (e.g. called IsManual) with default value set to False so every time the build is triggered by CI it will take the default value.

When you manually queue the build you'll have to change the variable value.