TFS API: Clone Build Definition Environment - powershell

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.

Related

How can I delete an Azure DevOps build definition that it claims is retained by a release?

I'm trying to delete an Azure DevOps build definition but it won't let me since it says:
"One or more builds associated with the requested pipeline(s) are retained by a release. The pipeline(s) and builds will not be deleted."
However there's no obvious way to see what release is causing a build to be retained. I tried searching online, of course, but all the examples/screenshots of how to do this in the web UI are showing UI from several iterations ago of the Azure DevOps website so none of the controls look the same anymore. I don't see a lock icon anywhere, for example.
How can I find the releases that are holding onto these build definitions so I can delete them and then delete the build definition?
Thanks!
When you open the build pipeline to see its detailed build records, you can see the relevant release name and its link:
On old pipeline version, there had a lock icon which can obvious let us know it is retained. In fact, the lock icon not only means it is retained by release, manual build retain also show this icon. But, seems we missed this obvious icon while we expand the new sprint.
As a workaround to get list of builds which retained by release, here has a short script can help you achieve by using Rest api:
$token = "{PAT token}"
$url ="https://dev.azure.com/{org name}/{project name}/_apis/build/builds?api-version=5.1"
$token = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes(":$($token)"))
$response = Invoke-RestMethod -Uri $url -Headers #{Authorization = "Basic $token"} -Method Get
$results = $response.value | Where {$_.retainedByRelease -eq "true"} #|
Write-Host "results = $($results.id | ConvertTo-Json -Depth 100)"
First, use list builds api to get all builds that in current project. Then for the builds which retained by release, since there has a parameter can indicate it: retainedByRelease here I use $_.retainedByRelease -eq "true" to get the builds list which actual retained by release:
The above script is very universal, can be used in Powershell-ise and Powershell Command Line and the Powershell task of VSTS without change anything.
Update in 11/19:
Based on #Auth's comment, if want to get its associated release, the most easiest way is find the build, and then check its associate release pipeline as the screenshot shown I shared above.
If this does not satisfied what you want, and the previous API we used does not include any releases info in that, so here, you need use this API: Releases - Get Release:
GET https://vsrm.dev.azure.com/{org name}/{project name}/_apis/release/releases?sourceId={project id}:{build definition id}&api-version=5.1
In this API, you need specified the project id:build definition id to filter releases.
With the icon missing, will let the corresponding team know and try to add it in the future sprint.
I have had this issue when some one delete a repository that was associated with a "POC" pipeline. I was not able to delete the pipeline.
When I tried to delete the pipeline, I got following message:
One or more builds associated with the requested pipeline(s) are retained by a release. The pipeline(s) and builds will not be deleted.
I did following steps to delete the pipeline:
My Goal was to delete PublishBuildArtifacts-Infrastructure pipeline as shown in image. So I clicked on the pipeline.
I see list of Builds (Runs) that is associated with my pipeline. I click on the 3 dots and click on View Retention Lease.
Then I click Remove all.
Now you can delete your build.
Repeat steps 2-4 for each run. When you have delete all builds, now you can delete the pipeline by clicking on the 3 dot menu, as shown in the image below.
Enjoy!

VSTS - unpromote a package version from release view

Our projects is currently using VSTS (Visual Studio Team Services) packages for sharing packages between projects. We want to adopt the Release Views feature to pick up packages at different stages of maturity for automated releases to different environments.
While it is pretty easy to promote a package to a specific view, I have not found a way to unpromote the package from that view. This could be needed for a couple of reasons:
Package was promoted by mistake.
Package needs to be unpromoted because of some issues found and thus needing to demote it to a lower maturity level.
I did not find a direct way of doing it via the VSTS user interface. I did find some articles of doing it via REST APIs, but looks like the current APIs under the Feeds don't support this any more.
Does anyone know how to achieve this?
For now, there is no way to unpromoted packages in VSTS package management.
And I posted an user voice Enable to unpromote package in VSTS package management and update REST API document, which suggests to add the feature to unpromote packages and update the REST API document. You can vote and follow up.
And the REST API to promote a NuGet package as below:
PATCH https://{account}.pkgs.visualstudio.com/DefaultCollection/_apis/packaging/feeds/{feedId}/nuget/packages/{packageId}/versions/{packageVersion}?api-version=5.0-preview.1
application/json:
{
"views":
{ "op":"add",
"path":"/views/-",
"value":"release view" }
}
Note:
For feedId and packageId in request URL, you can use feed name and package name instead.
For REST API versions, you can also use the older version like 3.0-preview.1.
As below example to promote nuget package ConsoleApp1 with version 1.5.0-alpha in new feed for pre view, the REST API is (response with 202 Accepted state if success):
And use the PowerShell to achieve the example, and script can be:
$releaseViewURL = "https://marinaliu.pkgs.visualstudio.com/DefaultCollection/_apis/packaging/feeds/new/nuget/packages/ConsoleApp1/versions/1.5.0-alpha?api-version=5.0-preview.1"
$json = '
{
"views":
{ "op":"add",
"path":"/views/-",
"value":"pre" }
}
'
$bodyJson=$json | ConvertFrom-Json
$user="name"
$token="p1tjzehdq6tilwfjdbgbkymo3f3ojszmrlfgzh302fww6kgwnavq"
$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $user,$token)))
$response = Invoke-RestMethod -Uri $releaseViewURL -Headers #{Authorization=("Basic {0}" -f $base64AuthInfo)} -ContentType "application/json" -Method Patch -Body $bodyJson

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.

Accessing AppVeyor Project Environment Variables during manual deploy

I'm new to AppVeyor, I work for a web agency where we have many projects in separate GIT repos.
Each project has a development branch which is what I'm watching in AppVeyor. Since we have a single internal development server running IIS, it was a good candidate to define our development server as an AppVeyor Environment. The development server is running the AppVeyor Agent.
Inside the project specific YAML files I'm specifying the environment name and a custom environment variable which I've defined.
environment:
iis_site_name: project-specific-site-name.com
deploy:
- provider: Environment
name: dev-environment
I've configured the AppVeyor environment to accept the environment variable from the project like this.
AppVeyor Environment - Note: websitebuild is the "deploy name" associated with the artifact.
This work's perfectly on a commit, the project is built and deployed to the Agent in the correct location.
Where this is not working is when I need to kick off a manual deploy. So lets say I want to kick off a manual deploy by going into the AppVeyor interface and selecting Environments > Dev Environment > New Deploy > Select Project
When this deploy runs the environment variable from the YAML file (iis_site_name) is not seen and a new IIS site named 'default' is created and the site is deployed there.
Note that I have also tried adding the environment variable in the project settings via the GUI (as opposed to in the YAML) and it behaves no differently.
I believe it is expected behavior, when build-time environment variables are not available, Appveyor will send to agent default value which you define at Environment level variables. Please look here
At the bottom of that screen we are defining its “default” value, i.e.
the value used when you deploy from Environments and build environment
variables are not present
As I understand this does not fit your scenario, because you need different site name for different projects. What you can do is to create separate Environment for every project (with separate default site names), but replace all their environment access keys with the same you use for you current environment, thus agent will pick up jobs from all of them.
Update:
This is not best solution according to Marty’s comments. Lets use REST API then.
Documentation is here https://www.appveyor.com/docs/api/environments-deployments/#start-deployment
Check sample PowerShell function below. You can just call it with project-specific parameters when needed.
Note that you also have to set websitebuild.hostname to $(iis_site_name) in Deployment provider setting for sites use host header instead of * bindings on IIS, otherwise they will fight over the TCP port ;)
function start-appveyorDeploy
{
param (
[Parameter(Position=0, Mandatory=$true)]
[string]$projectSlug,
[Parameter(Position=1, Mandatory=$true)]
[string]$buildVersion,
[Parameter(Position=2, Mandatory=$true)]
[string]$siteName
)
$apiUrl = 'https://ci.appveyor.com/api'
# Replace this with your values
$token = <your_token>
$environmentName = <your_environmentName>
$accountName = <your_accountName>
$headers = #{
"Authorization" = "Bearer $token"
"Content-type" = "application/json"
}
$body = #{
environmentName=$environmentName
accountName=$accountName
projectSlug=$projectSlug
buildVersion=$buildVersion
environmentVariables =#{
iis_site_name=$siteName
}
}
$jsonBody = $body | ConvertTo-Json -Depth 3
Invoke-RestMethod -Uri "$apiUrl/deployments" -Headers $headers -Body $jsonBody -Method Post
}

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.