How do I call Azure DevOps API for latest successful pipeline run? - powershell

I'm trying to accomplish what's described here by fearnight as a means of getting the commit ID of the most recent successful pipeline run, but I'm having trouble with the API call itself.
The API endpoint is described here and looks like this: GET https://dev.azure.com/{organization}/{project}/_apis/build/latest/{definition}?api-version=6.0-preview.1
The problem I'm having with it is that I don't know what to use for the "definition" segment. So I figured I could list out some information about my builds using this call. I attempted this using code like this in my pipeline:
- task: PowerShell#2
inputs:
targetType: 'inline'
script: |
$uri="https://dev.azure.com/mycompany/myproject/_apis/build/builds?resultFilter=succeeded&api-version=6.1"
$builds=(Invoke-RestMethod -Uri $uri -Method GET -Headers #{ Authorization = "Bearer $(System.AccessToken)" })
echo "Response: $builds"
echo "Builds: $builds.Build[0].definition.name"
# echo "name: $builds[0].definition.name"
# echo "definition ID: $builds[0].definition.id"
# $builds | ForEach-Object {
# echo "Build definition name: $_.definition.name"
# }
I must be coding these calls incorrectly, though, as this is typical of the responses I get:
========================== Starting Command Output ===========================
/usr/bin/pwsh -NoLogo -NoProfile -NonInteractive -Command . '/home/vsts/work/_temp/2ec4dfbd-d2d6-42e4-bd9e-9dfa3bad28f0.ps1'
Response: #{count=1000; value=System.Object[]}
Builds: #{count=1000; value=System.Object[]}.Build[0].definition.name
Finishing: PowerShell
To reframe my question, I need help with the syntax for querying the ADO API, which in turn I need to do for the purpose of getting the commit ID of the last successful run for my pipeline.
Can someone please help me out?
EDIT
I've got the endpoint call working (I think) now, as I'm getting a response back, but I can't figure out how to access the values in the response from within my pipeline PS script. I'd think that to access one of these properties (e.g., sourceVersion, which is the one I need), I could do something like one of these:
$response=(Invoke-RestMethod -Uri $uri -Method GET -Headers #{ Authorization = "Bearer $(System.AccessToken)" })
echo "Response: $response"
echo "Source version: $response.value"
# echo "Source version: $response.Build.sourceVersion"
All these give me, though is:
Response: #{_links=; properties=; tags=System.Object[] ... sourceVersion=fb29c721eaaaacf47f35ff900fe7086084cd321356;
How do I access and use the sourceVersion value?

Okay to get the commit ID associated with your latest pipeline run, refer to this SO answer:
https://stackoverflow.com/a/60500333/13761014
I'll keep it easy for others to follow, by adding the API here below:
GET https://dev.azure.com/{org name}/{project name}/_traceability/runview/changes?currentRunId={build id}&__rt=fps&__ver=2
To get the latest build id, refer to this API:
https://learn.microsoft.com/en-us/rest/api/azure/devops/build/latest/get?view=azure-devops-rest-6.0
Once you have the response from the first API, you'll need to query for the key
"ms.vss-traceability-web.traceability-run-changes-data-provider"
This will give you the ID of the repositories and the commit IDs associated to the build.
Hope this is what you were looking for.

Please use the pipeline's definition ID as the variable of "definition" segment like below:
https://dev.azure.com/{organization}/{project}/_apis/build/latest/138?api-version=6.0-preview.1
You can find the definition id in the url of your pipeline:

Related

Don't trigger builds for branches that already have a pull request in Azure DevOps

We use Azure DevOps for continuous integration. The pipeline is configured to run a build whenever a change is pushed to a feature branch. This is desired for quick feedback.
Additionally, we have the policy for the master branch that a successful validation build is required before a feature branch can be merged. Azure DevOps now automatically triggers the corresponding validation build when a pull request (PR) is created for a feature branch.
All of this is fine, but there is an adversity: if a PR is already created and the feature branch is updated, two builds are triggered (one for the feature branch alone and one for the outcome of the merge, i.e., the validation build).
I understand that some people might want both builds, but in our case (an probably in every normal case) it would be better if only the validation build was triggered.
Question: Is there a way to tell Azure DevOps that it should ignore branch triggers for any branch that already has a PR? Workarounds with an equivalent outcome are also welcome, of course.
The question has already been posted as an issue here, but I could not find a satisfying answer in the replies (e.g., branch filters and a naming strategy do not solve the problem).
"Out-of-box" - you can not. However as a workaround, you can use rest API to check active pull requests and if they exist just fail your unneeded build:
Get Pull Requests - Targeting a specific branch
Use the system access token from your build pipeline. Access repositories, artifacts, and other resources
Exit with Powershell from a build: exit 1
Because that's the design, thus, both build will be triggered but you could have try with follow method to avoid the build queued at the same time.
In the build validation policy - disable automatic queuing. Or mark the PR as draft, while changes are being worked on. After this change any of the changes will only trigger CI build/pipeline, and when ready just publish the PR or queue the PR manually.
I have solved the issue like suggested by Shamrai. I'm adding this as another answer to share my code.
Add the following PowerShell code to a step at the beginning of the pipeline. It uses the Azure DevOps REST API to check for an existing PR of the current branch. If there is no such PR or if the current build was manually queued, or if the PR is not ready to be merged (e.g. conflicts), the build continues as normal. Otherwise, it is cancelled.
$BaseApiUri_Builds = "https://my.tfs.server.com/MyCollection/MyProject/_apis/build/builds"
$BaseApiUri_GitRepos = "https://my.tfs.server.com/MyCollection/MyProject/_apis/git/repositories"
$AuthenicationHeader = #{ Authorization = "Bearer ${env:System_AccessToken}" }
# Cancels the current build
function Cancel-This-Build()
{
Cancel-Build -BuildId ${env:Build_BuildId}
}
# Cancels the given build
function Cancel-Build([String] $BuildId)
{
Write-Host "Cancelling build ${BuildId}..."
$BuildApiUri = "${BaseApiUri_Builds}/${BuildId}?api-version=5.1"
$CancelBody = #{ status = "cancelling" } | ConvertTo-Json
Invoke-RestMethod -Uri $BuildApiUri -Method PATCH -ContentType application/json -Body $CancelBody -Header $AuthenicationHeader
}
# Detects if a validation build is queued for the given branch. This is the case if an active PR exists that does not have merge conflicts.
function Check-For-Validation-Build([String] $BranchName)
{
Write-Host "Checking for validation builds of branch '${BranchName}' in repository ${env:Build_Repository_ID}..."
$GetPRsApiUri = "${BaseApiUri_GitRepos}/${env:Build_Repository_ID}/pullrequests?api-version=5.1&searchCriteria.sourceRefName=${BranchName}"
$PRs = Invoke-RestMethod -Uri $GetPRsApiUri -Method GET -Header $AuthenicationHeader
ForEach($PR in $PRs.Value)
{
Write-Host "Found PR $($PR.pullRequestId) '$($PR.title)': isDraft=$($PR.isDraft), status=$($PR.status), mergeStatus=$($PR.mergeStatus)"
if (!$PR.isDraft -and ($PR.mergeStatus -eq "succeeded") -and ($PR.status -eq "active"))
{
Write-Host "Validation build is queued for branch '${BranchName}'."
return $true
}
}
Write-Host "No validation build is queued for branch '${BranchName}'."
return $false
}
# Check if a valid PR exists. If so, cancel this build, because a validation build is also queued.
$HasValidationBuild = Check-For-Validation-Build -BranchName ${env:Build_SourceBranch}
if (($HasValidationBuild -eq $true) -and (${env:Build_Reason} -ne "Manual") -and !${env:Build_SourceBranch}.EndsWith('/merge'))
{
Cancel-This-Build
}
Note that the System.AccessToken environment variable must be made visible for the script to work.

Reference Wiki page from inside customized work item

I have created a customized work item. It there any way to link this work item with pre-created wiki page. I don't want to link it with work item manually, just kind of automatic link when create a new work item.
The most convenient workaround is to create a custom field for your work item. And create a rule to automatically set the wiki page url as value of the custom field.
Check tutorial here to Add a custom field.
Check here to Add a rule to a work item type, which will be triggered when a work item is created, and set the wiki url as the custom field value.
There is another workaround using azure pipeline and rest api.
Please check below steps:
1, create web hook to be triggered by Work item created event
When creating your webhook, you need to provide the following info:
Request Url - https://dev.azure.com/<ADO Organization>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview
Secret - This is optional. If you need to secure your JSON payload, provide the Secret value
2, Create a new "Incoming Webhook" service connection.
Webhook Name: The name of the webhook should match webhook created in your external service.
3, Create a yaml pipeline.
Add service connection resources in the yaml pipeline see below:
resources:
webhooks:
- webhook: MyWebhookTrigger
connection: MyWebhookConnection #the name of the Incoming Webhook service connection created in above step.
Add script task in your pipeline to call work item update rest api. See below scripts:
steps:
- powershell: |
$workitemId= ${{ parameters.MyWebhookTrigger.resource.id}}
$url = "$(System.TeamFoundationCollectionUri)$(System.TeamProject)/_apis/wit/workitems/$($workitemId)?api-version=6.1-preview.3"
$body ='
[
{
"op": "add",
"path": "/relations/-",
"value": {
"rel": "ArtifactLink",
"url": "vstfs:///Wiki/WikiPage/{projectName}/{wikiName}/{wikiPage}",
"attributes": {
"name": "Wiki Page"
}
}
}
]'
Invoke-RestMethod -Uri $url -Headers #{Authorization = "Bearer $(system.accesstoken)"} -ContentType "application/json-patch+json" -Method patch -body $body
Please check out this document for more information.
Above steps actually do below things:
New workitem is created-->automatically Trigger Azure pipeline-->Azure pipeline run script to call rest api to add the wiki page to the workitem.

Create bug in a different project when build fails

We have setup a build definition which creates a bug and assigns it to "requestor" incase the build fails. See below :
By default, the bugs are created in the same project. How do I change this to create the bugs in a different project ? The reason is, our work item tracking is in a different project than our Git repos (due to reshuffling and what not). Note that both the projects are under the same account.
Looking at the tool tip, it provides some sample fields, is there a corresponding field for "project" ? (System.Project ?!)
The Create work item on failure option in VSTS build can only create work item in the same project.
The workaround to create a Bug if build failed can be achieved by adding a PowerShell task. Detail steps as below:
1. Add a PowerShell in the end of your build definition
In the PowerShell script, you can create a Bug for a different project by REST API. Below is an example script:
$witType="Bug"
$witTitle="Build $(build.buildNumber) failed"
$u="https://account.visualstudio.com/DefaultCollection/project/_apis/wit/workitems/`$$($witType)?api-version=1.0"
$body="[
{
`"op`": `"add`",
`"path`": `"/fields/System.Title`",
`"value`": `"$($witTitle)`"
}
]"
$user = "user"
$token = "PAT"
$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $user,$token)))
$result=Invoke-RestMethod -Method PATCH -Uri $u -Headers #{Authorization=("Basic {0}" -f $base64AuthInfo)} -ContentType "application/json-patch+json" -Body $body
2. Specify Run this task option as Even if a previous task has failed, unless the build was canceled
From Second task to the end task (PowerShell task), change Run this task option as Even if a previous task has failed, unless the build was canceled:
So when build fails, a Bug will be create to the different project as you specified in PowerShell script.
You can not do this out-of-the-box, but ...
You could do it using the API, something like this:
1 - Add a task to the build process to call a rest API and call the api to create a workitem. See https://www.visualstudio.com/en-us/docs/integrate/api/wit/work-items#create-a-work-item
2 - Change your agent phase to allow access to the token. Your task will need this.
3 - Change your task in Control Options and change the "Run this task" to "Custom condition" and fill the field with
eq(variables['Agent.JobStatus'], 'Failed')
Ref https://learn.microsoft.com/en-us/vsts/build-release/concepts/process/conditions?view=vsts
This should do it.

TFS API: Clone Build Definition Environment

I want to clone an existing environment within a build definition.
This is possible through the TFS GUI, but it doesn't seem like the API natively supports it.
So far, I've tried the following (in PowerShell):
Download build definition and deserialize
[void][System.Reflection.Assembly]::LoadFile("$pwd\Newtonsoft.Json.dll")
$TargetDefinitionName = "Name"
$TargetDefinitionID = ($DefinitionsOverview | Where-Object { $_.name -eq $TargetDefinitionName } | Select-Object -First 1).id
$TargetDefinitionURL = "$TfsUri/$TargetDefinitionID"
$TargetDefinitionJSON = Invoke-WebRequest -Uri "$TargetDefinitionURL" -UseDefaultCredentials
$DeserializedBuildDefinition = [Newtonsoft.Json.JsonConvert]::DeserializeObject($TargetDefinitionJSON.Content)
$DeserializedBuildDefinition.ToString()
Duplicate JSON block that represents environment, change unique properties
$NewEnvironmentString = $DeserializedBuildDefinition.environments[4].ToString()
$DeserializedBuildDefinition.environments.Add(5)
$DeserializedBuildDefinition.environments[5] = $NewEnvironmentString
$DeserializedBuildDefinition.environments[5].name.value = "NewEnvironment"
$DeserializedBuildDefinition.environments[5].rank.value = "6"
$DeserializedBuildDefinition.environments[5].id.value = "1665"
$DeserializedBuildDefinition.revision.value = "20"
Serialize JSON and post back (with new environment)
$SerializedBuildDefinition = [Newtonsoft.Json.JsonConvert]::SerializeObject($DeserializedBuildDefinition)
$PostData = [System.Text.Encoding]::UTF8.GetBytes($SerializedBuildDefinition)
$Headers = #{ "Accept" = "api-version=2.0-preview" }
$Response = Invoke-WebRequest -UseDefaultCredentials -Uri
$TargetDefinitionURL -Headers $Headers `
-Method Put -Body $PostData -ContentType "application/json"
$Response.StatusDescription
PROBLEM: $Response.StatusDescription gives "OK," but no new environment appears in the build definition.
One thought is that, in addition to 'name,' 'ID,' and 'rank, there are other values that need to be unique per environment that I'm missing.
I've also tried cloning the environment manually, saving the JSON representation of the definition, deleting the environment, and posting the JSON back. The new environment still doesn't show up.
Any help would be appreciated.
Future: Yaml based build definitions as code are well on their way, at least to VSTS. This won't help an immediate need but probably offers a better and more lightweight future approach.
When you copy an environment, you need to change "id", "name", and "rank". And the “id” need to be changed to "0". Also, try to use api-version=2.3-preview.1.
Then use the api of update a release definition to update the definition:
PUT http://tfs2015:8080/tfs/teamprojectcollection/teamProject/_apis/release/definitions?api-version=2.3-preview.1
{
……
}
I have tested with TFS 2015 Update 4. Api could clone an environment successfully.
I created a tool for cloning TFS builds, as (with TFS 2015 update 1 at least) the web 'clone' function does not clone the 'Repository' or 'Triggers' tab. Some of our build steps were a little complicated so I also wrote some simple transforms to automatically set the values according to the target branch.
I used the BuildHttpClient object in Microsoft.TeamFoundation.Build2.WebApi assembly to get the original build definition (BuildDefinition object, using GetDefinitionAsync() method), transform any build steps values, then call CreateDefinitionAsync() on BuildHttpClient to create the new build.
Works very reliably and under the hood it appears to use the TFS REST API.
If there was any interest, I'd be happy to create a more in depth tutorial on this.

Get Build status by Commit SHA1

Our team is using TeamCity for continuous integration and Git-TFS (TFS2015 RC) for versioning.
I want to check if a specific Commit has been built (successfully) by TeamCity and thus can be reintegrated.
It is possible to query TeamCity builds by using their REST API, e.g.:
GET http://teamcity:8000/guestAuth/app/rest/builds/18
with the result containing some xml that shows the git commit SHA:
<revisions count="1">
<revision version="96b1db05b64ecc895da070137e93cde3d2cadfa1">
<vcs-root-instance [...]/>
</revision>
</revisions>
The fact, that this information is in theory available, makes me hope that it is possible to query TeamCity builds by this particular information, like:
GET http://teamcity:8000/guestAuth/app/rest/builds/revision:96b1db05b64ecc895da[...]
but this yields a #400 BAD REQUEST response. I was not able to find out in the TeamCity 9 Documentation, whether this is possible or not. I would rather not iterate all builds to check if they contain this specific commit.
NOTE: This feature has now been implemented by JetBrains and is available in TeamCity 9.1 EAP4 now.
I don't believe this can be done without iteration, which is a little annoying
You can view changes by hash
/httpAuth/app/rest/changes?version:SHA_HASH
and you can find changes by build locator
/httpAuth/app/rest/changes?locator=build:(id:BUILD_ID)
but you can't go the other way, otherwise this could be done simply.
The buildLocator doesn't allow you to query using a revision dimension so I can't see any way around this
The following script may be of use to you if you haven't already written it yourself - save this to a file called get-build-status-by-git-commit.ps1 so it works with the sample at the end
# -----------------------------------------------
# Get Build Status By Git Commit
# -----------------------------------------------
#
# Ver Who When What
# 1.0 DevOpsGuys 01-07-15 Initial Version
# Script Input Parameters
param (
[ValidateNotNullOrEmpty()]
[string] $TeamCityServer = $(throw "-TeamCityServer is mandatory, please provide a value."),
[ValidateNotNullOrEmpty()]
[string] $ApiUsername = $(throw "-ApiUsername is mandatory, please provide a value."),
[ValidateNotNullOrEmpty()]
[string] $ApiPassword = $(throw "-ApiPassword is mandatory, please provide a value."),
[ValidateNotNullOrEmpty()]
[string] $GitSha = $(throw "-GitSha is mandatory, please provide a value.")
)
function Main()
{
$CurrentScriptVersion = "1.0"
$ApiCredentials = New-Object System.Management.Automation.PSCredential($ApiUsername, (ConvertTo-SecureString $ApiPassword -AsPlainText -Force))
Write-Host "================== Get Build Status By Git Commit - Version"$CurrentScriptVersion": START =================="
# Log input variables passed in
Log-Variables
Write-Host
# Set initial query url
$queryBuilds = "/httpAuth/app/rest/builds?fields=nextHref,build(id,status,revisions)"
while($queryBuilds)
{
$buildsToCheck = Api-Get "$TeamCityServer$queryBuilds"
$queryBuilds = $buildsToCheck.builds.nextHref;
foreach($build in $buildsToCheck.builds.build)
{
if ($build.revisions.revision.version -eq $GitSha) {
Write-Host "STATUS: "$build.status
Exit 0
}
}
}
Write-Host "================== Get Build Status By Git Commit - Version"$CurrentScriptVersion": END =================="
}
function Log-Variables
{
Write-Host "TeamCityServer: " $TeamCityServer
Write-Host "GitSha: " $GitSha
Write-Host "Computername:" (gc env:computername)
}
function Api-Get($Url)
{
Write-Host $Url
return Invoke-RestMethod -Credential $ApiCredentials -Uri $Url -Method Get -TimeoutSec 20;
}
Main
You can use this in the following way
.\get-build-status-by-git-commit.ps1 "http://teamcity:8000/" username password 96b1db05b64ecc895da070137e93cde3d2cadfa1
This is using httpAuth, but you could easily tailor the script to be using guest. I've used httpAuth in case it's of use to anyone else.
Hope this helps
I was looking for the same thing and stumbled upon this question. I don't know if you still need this but however I found the API in TeamCity v10. But you have to know your BuildTypeID for this
https://${teamcity.domain}/app/rest/buildTypes/id:${BuildTypeID}/builds/revision:${COMMIT_SHA}
You can find your build type id from TeamCity UI by going to your specific build and then
Edit configuration settings >> General Settings
And then the value in the Build configuration ID field.
Hope this helps.
The related feature request in TeamCity issue tracker: https://youtrack.jetbrains.com/issue/TW-40540. Vote for it.
The current workaround is to request builds with their revisions included into the response and then find the necessary builds on the client side.
The request can look like:
.../app/rest/builds?locator=buildType(id:XXX)&fields=build(id,href,revisions(revision))
Recent versions of teamcity allow the 'version' locator such that the following will return builds where the version SHA matches the query.
http://teamcity:8111/app/rest/changes?locator=version:SHA_HASH
I'm on TeamCity 2019.2, and I was able to directly search the builds endpoint for a specific commit:
TEAMCITY_URL/app/rest/builds/revision:SHA_HASH.
Not sure what version it was implemented in.