Ask Learn
Preview
Ask Learn is an AI assistant that can answer questions, clarify concepts, and define terms using trusted Microsoft documentation.
Please sign in to use Ask Learn.
Sign inThis browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
When switching from XAML to vNext, I realized the newer build model doesn’t update Global List. Old XAML builds enabled a work flow where work items were created on build failure and then updated those work items, associated with check-ins on successful builds. I couldn’t find a similar feature happening out of the box on the vNext model. However I was able to write a sample script to work around and get similar features. In this blog, I am going to explain the same in detail.
Found in build field:
Field - Microsoft.VSTS.Build.FoundIn and Value - $ (Build.BuildNumber)
This would create a new work item on build failure with the failing build set.
Integrated in build work flow:
Using XAML templates, you might have noticed the “Integrated in Build” field is auto updated by the build process which picks up the bug resolution through a changeset at check-in time, however it’s not the case in Vnext and switching to Vnext you might want this updated, hence this blog post.
In order to get the “Integrated in Build” updated, the following steps will help.
Using PowerShell, we will find the work item associated with the build in progress.
On success of the build, using REST API we will update the “Integrated in build” field with the build number.
Step 1:
Add two variables to the build definition.
RestUserName -> Service account (or any other account that can access TFS)
RestPassword -> Password for the account (encrypted so that it’s secure)
Step 2: Create a PowerShell file and copy the content below.
param(
$RestUserName,
$RestPassword
)
$basicAuth = ("{0}:{1}" -f $RestUserName, $RestPassword)
$basicAuth = [System.Text.Encoding]::UTF8.GetBytes($basicAuth)
$basicAuth = [System.Convert]::ToBase64String($basicAuth)
$headers = @{Authorization=("Basic {0}" -f $basicAuth)}
[String] $CollectionURL = “$env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI“
[String] $BuildUrl = “$env:BUILD_BUILDURI“
[String] $project = “$env:SYSTEM_TEAMPROJECT“
[String] $BuildId = "$env:BUILD_BUILDID"
[String] $BuildNumber = "$env:BUILD_BUILDNUMBER"
Try
{
$WorkItemAssociatedURL = $collectionURL + $project + "/_apis/build/builds/" + $BuildId + "/workitems?api-version=2.0"
$ResponseJSON = Invoke-RestMethod -Uri $WorkItemAssociatedURL -ContentType "application/json" -headers $headers -Method GET
$CountWorkitems = $ResponseJSON.count
$WorkitemUrlArray = $ResponseJSON.value
for($i = 0; $i -lt $CountWorkitems ; $i++)
{
$body =
'[
{
"op": "add",
"path": "/fields/Microsoft.VSTS.Build.IntegrationBuild",
"value":' + $BuildNumber +'
}
]'
$WorkitemUpdateURL = $WorkitemUrlArray[$i].url + "?api-version=1.0"
Invoke-RestMethod -Uri $WorkitemUpdateURL -Body $body -ContentType "application/json-patch+json" -headers $headers -Method Patch
}
}
Catch
{
Write-Host "No work item associated with this build. Kindly check the changesets"
}
Step 3: Add a PowerShell task at the very end of the build definition and then select the PowerShell.
In the Arguments pass the UserName and Password -> $(RestUserName) $(RestPassword)
On build, we will see this behavior
This works for both VSTS and OnPrem TFS. However setting authentication for REST API differs on both. Getting started with REST can be found here.
Content : Venkata Narasimhan
Reviewer: Vimal Thiagaraj
Ask Learn is an AI assistant that can answer questions, clarify concepts, and define terms using trusted Microsoft documentation.
Please sign in to use Ask Learn.
Sign in