Is there a way to post build results from the build system (vNext?) in the Team Rooms?
I noticed there is an option to post build results in the team rooms, but the available list to choose from are only XAML build definitions and not the new build system (vNext?) definitions.
No there is not.
I have logged the issue here : https://connect.microsoft.com/VisualStudio/Feedback/Details/1874524
I have try it on my environment(TFS2015&VS2015) .
Sorry about that, this function seems only support XAML build by now.
You can raise your requirements to Microsoft.
The following Powershell code is a first attempt at getting something working for us:
Param($teamroom,$message)
# Example: Write-MessageToTeamRoom.ps1 -teamroom "Team Room Name" -message "Notify #User name about work item #54142"
# https://jaspergilhuis.nl/2014/02/18/utilize-the-tfs-team-room-rest-api/
# https://jaspergilhuis.nl/2014/02/23/encapsulate-team-room-api-calls-with-a-powershell-commandlet/
$rooms = Invoke-RestMethod -Method GET http://tfsapp02:8080/tfs/defaultcollection/_apis/chat/rooms?api-version=1.0 -UseDefaultCredentials
$room = $rooms.value | Where-Object {$_.Name -eq $teamroom}
$relevantRoomID = $room.id
$jsonbody = #{ content="$message"} | ConvertTo-Json
$response = Invoke-RestMethod -Method POST "http://{TfsDefaultCollectionPath}/_apis/chat/rooms/$relevantRoomID/messages?api-version=1.0" -Body $jsonbody -ContentType "application/json" -UseDefaultCredentials
My ambition is to expand this code to run whenever a build completes and then write the build result into the team room
Related
I am trying to list all work item type states for an organisation (visible to the authenticated user) via REST API. It seemed more efficient to list all processes (https://learn.microsoft.com/en-us/rest/api/azure/devops/core/processes/list?view=azure-devops-rest-4.1) and then use the endpoint to list all work item types of those processes together with the states (https://learn.microsoft.com/en-us/rest/api/azure/devops/processes/work-item-types/list?view=azure-devops-rest-4.1&tabs=HTTP). However, I am missing some custom states in the response.
When I list all projects (https://learn.microsoft.com/en-us/rest/api/azure/devops/core/projects/list?view=azure-devops-rest-4.1&tabs=HTTP), then all work item types of those projects (https://learn.microsoft.com/en-us/rest/api/azure/devops/wit/work-item-types/list?view=azure-devops-rest-4.1&tabs=HTTP) and then all states of those types (https://learn.microsoft.com/en-us/rest/api/azure/devops/wit/work-item-type-states/list?view=azure-devops-rest-4.1&tabs=HTTP), there is everything. But that is sooo many requests.
Can someone explain, why is the first approach not working? Every projet should be associated with a process. Or not? Do you know a better way to get all those states as efficiently as possible?
Thanks in advance. :)
As we can see from the official documentation : Work Item Type States - List, it's in project level not the organization level. So, we need to get the states by project scope.
GET https://dev.azure.com/{organization}/{project}/_apis/wit/workitemtypes/{type}/states?api-version=4.1-preview.1
We can write a script to retrieve the projects and work item types in a loop, then get the states of each work item type.
UPDATE:
We can use States - List REST API to return a list of all state definitions in a work item type of the process.
Below PowerShell script for your reference to return the states from a specific process:
Param(
[string]$orgurl = "https://dev.azure.com/{org}",
[string]$processname = "Your-Process-Name",
[string]$user = "",
[string]$token = "PAT"
)
# Base64-encodes the Personal Access Token (PAT) appropriately
$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $user,$token)))
#Get Process ID
$processesurl = "$orgurl/_apis/process/processes?api-version=6.0"
$processes = (Invoke-RestMethod -Uri $processesurl -Method Get -Headers #{Authorization=("Basic {0}" -f $base64AuthInfo)}).value | where {$_.name -eq $processname }
$processesid = $processes.id
#List Work item types and witRefName
$witsurl = "$orgurl/_apis/work/processes/$processesid/workitemtypes?api-version=6.0"
$witRefNames = (Invoke-RestMethod -Uri $witsurl -Method Get -Headers #{Authorization=("Basic {0}" -f $base64AuthInfo)}).value.referenceName #| where {$_.name -eq $processname }
#List WIT states
foreach ($witRefName in $witRefNames){
$statesurl = "$orgurl/_apis/work/processes/$processesid/workItemTypes/$witRefName/states?api-version=6.0"
$states = (Invoke-RestMethod -Uri $statesurl -Method Get -Headers #{Authorization=("Basic {0}" -f $base64AuthInfo)}).value.name
Write-Host "==================================================================================="
Write-Host "$witRefName - States:" $states
Write-Host "==================================================================================="
echo `n
}
If you want to retrieve all states from all processes, then you can get the processes and loop them in the script.
I am trying to force the run of a specific agent phase on a specific agent. My variable however does not seems to be picked up. I get the error:
No agent found in pool TEST which satisfies the specified demands:
Agent.Name -equals $(Release.ReleaseName)
vstest
Agent.Version -gtVersion 2.103.0
Is this possible?
I wanted to do something similar. I had 2 "environments" in the TFS release definition. The first one ("MyEnvironment-Setup") did setup like big file copies and database script generation. The second ("MyEnvironment") did the actual deployment. I needed them both to run on the same agent.
What I ended up doing is using the TFS API during "MyEnvironment-Setup" to modify the currently running release instance and set the agent demand for "MyEnvironment".
Several things were necessary to make this happen.
In "MyEnvironment-Setup" > Run on Agent > Additional Options, I enabled "Allow scripts to access the OAuth token"
In the left pane of the release definition screen where it lists all release definitions, I clicked the ellipsis next to "All release definitions" and selected "Security". Then for the "Project Collection Build Service (TEAM FOUNDATION)" user, I set "Edit release definition" and "Manage releases" to "Allow".
I called the following Powershell method in "MyEnvironment-Setup"
function Set-FinalAgent()
{
# Force the "MyEnvironment" step to run on the same agent as the "MyEnvironment-Setup" step
$baseApiUrl = "$($env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI)$env:SYSTEM_TEAMPROJECTID/_apis"
$apiVersion = "3.1-preview"
$header = #{ Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN" }
$environmentToModify = $($env:Release_EnvironmentName).Replace("-Setup", "")
$releaseID = $env:Release_ReleaseID
$release = Invoke-RestMethod -Uri "$baseApiUrl/release/releases/$($releaseID)?api-version=$apiVersion" -Method GET -Header $header
($release.environments | where name -eq $environmentToModify).deployPhasesSnapshot[0].deploymentInput.demands += "Agent.Name -equals $($env:Agent_Name)"
# Compression is needed for the body to contain all of the info for larger release definitions when running on older servers
$body = $release | ConvertTo-Json -Depth 100 -Compress
Invoke-RestMethod -Uri "$baseApiUrl/release/releases/$($releaseID)?api-version=$apiVersion" -Method PUT -Header $header -ContentType application/json -Body $body
}
If you want to test and tweak this in Powershell ISE or something where you don't have access to the OAuth token, you can use a personal access token instead. In the top-right of your TFS Web UI, click your profile picture and select "Security" to generate a PAT. Then you can replace the header in the script above with the following:
$header = #{Authorization = 'Basic ' + [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(":$($personalAccessToken)"))}
We're using Team Foundation Server 2017. After lots of releasedefinition-making, I'm stucking on a problem.
During the release, I receive a message which I would write directly into the release description summary. I checked for an such an activity in the Marketstore, but I haven't found one.
Am I not able to search for the right activity or is there another way for updating this?
Currently, you can only update release name with Logging command, which requires agent version 2.132+. So the only way to update the release description is adding a powershell script in your release definition. The script is as below:
param (
[Parameter(Mandatory=$true)]
[ValidateNotNullOrEmpty()]
[string] $token
)
## Construct a basic auth head using PAT
function BasicAuthHeader()
{
param([string]$authtoken)
$ba = (":{0}" -f $authtoken)
$ba = [System.Text.Encoding]::UTF8.GetBytes($ba)
$ba = [System.Convert]::ToBase64String($ba)
$h = #{Authorization=("Basic{0}" -f $ba);ContentType="application/json"}
return $h
}
$getReleaseUri = "http://TFS2017:8080/tfs/DefaultCollection/TeamProject/_apis/release/releases/$($env:RELEASE_RELEASEID)?api-version=3.2-preview"
$h = BasicAuthHeader $token
$release = Invoke-RestMethod -Uri $getReleaseUri -Headers $h -Method Get
# Update an existing variable named d1 to its new value d5
$release.description = "this is a test";
####****************** update the modified object **************************
$release2 = $release | ConvertTo-Json -Depth 100
$release2 = [Text.Encoding]::UTF8.GetBytes($release2)
$updateReleaseUri = "http://TFS2017:8080/tfs/DefaultCollection/TeamProject/_apis/release/releases/$($env:Release_ReleaseId)?api-version=3.2-preview"
$content2 = Invoke-RestMethod -Uri $updateReleaseUri -Method Put -Headers $h -ContentType “application/json” -Body $release2 -Verbose -Debug
write-host "=========================================================="
And with argument -token {PAT}. Check my screenshot below:
I've tested on my side, it can update release description successfully.
We have an orchestration build that we would like to set status to partially succeeded if it didn't do certain things. With Xaml builds, we could do it by setting the CompilationStatus and TestStatus of the build.
For Tfs Builds, I can am trying to it by setting calling the TFS Rest API to update the build result.
$query = [uri]::EscapeUriString("$tfsCollection$tfsProject/_apis/build/builds/$buildId`?api-version=2.0")
$request = "{""result"":""$result""}"
try {
$result = Invoke-RestMethod -Method PATCH -UseDefaultCredentials -ContentType "application/json" -Uri $query -Body $request
}
catch{
Write-Output "StatusCode:" + $_.Exception.Response.StatusCode.value__ +
"`r`nStatusDescription:" + $_.Exception.Response.StatusDescription
}
After the call, I can see that the ribbon of the build changes to orange indicating that is partially succeeded. However, it gets changed to succeeded when the Finalize Build step of build is run.
What should I do that the end build finishes with a status partially succeeded.
You can add a task with its control options set to "Continue on Error". Whenever this tasks fails, your build will be partially succeeded.
Im trying to queue a new build using the TFS 2015.3 REST API, i have followed many articles but cannot get it to work.
I am executing this in PowerShell, a standard queue new build call works when passing only the Definition ID, but passing anything else in addition to the id doesn't seem to work.
my code:
$buildDef = Invoke-RestMethod -Method Get -UseDefaultCredentials -Uri "$($tfsRoot)/_apis/build/definitions?api-version=2.0&name=$buildDefintionName"
$detailedResults = Invoke-RestMethod -Uri $buildDef.Value[0].Url -Method Get -ContentType "application/json" -UseDefaultCredentials
if ($buildDef.Value[0].Id)
{
$agentDemandString = "Agent.Name -equals $agent"
$demands = $detailedResults.Demands
$json = "definition: { id:$($buildDef.Value[0].Id) }, demands: $demands"
$bodyjson = $json | ConvertTo-Json
Write-Host "Queuing build $buildDefintionName on agent $agent with parameters $json"
$build = Invoke-RestMethod -Method Post -UseDefaultCredentials -ContentType application/json -Uri "$($tfsRoot)/_apis/build/builds?api-version=2.0" -Body $bodyjson
}
I have tried many different variations of passing the demands, but it looks like it is not even getting to that point as its complaining about the "build" parameter.
Invoke-RestMethod : {"$id":"1","innerException":null,"message":"Value cannot be null.\r\nParameter name: build","typeName":"System.ArgumentNullException, mscorlib, Version=4.0.0.0, Culture=neutral
If im right the build parameter contains the build steps to execute. Which makes me think that the queued build is dropping all existing configuration and tries to rely only on what has been passed in the JsonBody, this is ofcourse not what i want.
What and how should i pass in order to queue a new build but with updated/additional demands.
I finaly got it working with some help. The Demands property is accepted.
Looks like it was not working because of the powerShell code with Json conversion. If i use below and dont convert it to Json, it works !
Function queuebuild{
$uri="$($tfsRoot)/_apis/build/builds?api-version=2.0"
$body='{
"definition": {
"id": 1061
},
"sourceBranch": "$/Project/Branch",
"demands":["Demand1", "Agent.Name -equals Computer2-E-A2"]
}';
$result=Invoke-RestMethod -Uri $uri -Method Post -ContentType "application/json" -UseDefaultCredentials -Body $body
}
Try to set the depth:
$bodyjson = $json | ConvertTo-Json -Depth 3
$json = "definition: { id:$($buildDef.Value[0].Id) }, demands: $demands" is not going to be valid JSON -- it wouldn't be wrapped in curly braces, for example.
I recommend creating an associative array that will properly convert to valid JSON. The example JSON provided in the documentation is:
{
"definition": {
"id": 25
},
"sourceBranch": "refs/heads/master",
"parameters": "{\"system.debug\":\"true\",\"BuildConfiguration\":\"debug\",\"BuildPlatform\":\"x64\"}"
}
So this would generate an appropriate JSON object:
$body = #{
definition = #{ id=25 }
sourceBranch = 'refs/heads/master'
parameters = '{\"system.debug\":\"true\",\"BuildConfiguration\":\"debug\",\"BuildPlatform\":\"x64\"}'
}
$body | convertto-json
Or if you wanted to be extra fancy and eliminate the inner JSON-as-a-string bit:
$body = #{
definition = #{ id=25 }
sourceBranch = 'refs/heads/master'
parameters = (#{'system.debug' = $true; BuildConfiguration='debug'; BuildPlatform='x64'}) | convertto-json -Compress
}
$body | convertto-json
Based on my test, we cannot Set Demands directly with the Queue build REST Api.
The build will still use the agent which was set in definition even though we specified other agents with the "Demands" set when queue the build. You can check this with the REST API, below screenshot for your reference.
And with the REST API to get a build eg:
GET http://SERVER:8080/tfs/CollectionLC/6debd6ea-fa97-4ea2-b0c0-3cbbc4afa802/_apis/build/Builds/1071/
You can see that, the "Demands" is not included in the response. It only appears in build definition response.
Actually, the "Demands" is set in build definition,it's against the build definition only. When queue a build with REST API, it just trigger the build definition. So, if you want to trigger build with the specific agent using REST API, you need to update the definition (set demands )first, then trigger the build definition.
To update the definition use the REST API : See Update a build definition
PUT https://{instance}/DefaultCollection/{project}/_apis/build/definitions/{definitionId}?api-version={version}
So, you can write the script to update build definition fist, then trigger the build with build definition ID.