1
votes

Target Environment: TFS 2015 Update 3

We are attempting to get the vNext build system to allow us to to only associate Changesets and Work Items to a build once it is deployed via Release Management. However, the TFS vNext build system automatically associates these items to builds at build time (based on the last successful build). The old XAML build system had a property to turn this off called SkipGetChangesetsAndUpdateWorkItems, but it no longer exists in the new system.

Therefore, I need to add a task/script at the end of the vNext build process to remove these associations (and then add a similar task to Release Management to re-associate them). It's not the simplest task in the world, but it seems like something should be feasible via the TFS REST API.

However, I cannot for the life of me find out how these associations are formed. The JSON for the Changesets don't seem to mention an associated build, and the JSON for the build doesn't seem to mention a list of associated changesets.

How are these associations between Changesets/Work Items and builds defined?

1

1 Answers

1
votes

There is no such Rest API can achieve this of remove changeset. In XAML build, the related info are stored in a SQL table called dto.tbl_BuildDefinition, for which you want to reassociate changesets and change values in LastBuildUri, LastGoodBuildUri and LastGoodBuildLabel . Details please refer this link: Re-associate changesets and work items with build For vNext build definition, I didn't find something similar in SQL. However there must be some somewhere stored the association.

For the association between workitem and build, there is a method called $WorkItemAssociatedURL such as

$WorkItemAssociatedURL = $collectionURL + $project + “/_apis/build/builds/” + $BuildId + “/workitems?api-version=2.0”

$ResponseJSON = Invoke-RestMethod -Uri $WorkItemAssociatedURL -ContentType “application/json” -headers $headers -Method GET

For more detail info you can refer this blog: Build association with work Items in vNext