I am excited to see TFS Update 2 available for on premise and including the Release Management Feature part of the web experience. We have been waiting for this.
I need some help on how best to trigger the release.
A release can be triggered in 3 ways:
Continuous Deployment Trigger based on linking to TFS Build Definition
Manually
REST API
This is great but I don't think it fits what I would expect. I need help in a technical solve or in how I think about the problem.
My Thinking:
I believe the Build should create an artifact and put the artifact in a Drop location to be released now or a year from now. (need to rebuild or add a server later)
I feel the continuous deployment trigger breaks down as it depends on the artifact being in the TFS Build and the TFS Build will be deleted depending on your settings.
Possible Solution:
I believe the solution I need is to create a draft release using the REST Api and then pass in the path to the artifact in the drop location. In my case I would simply provide a version number and build the path inside the release.
Problem:
At this point the REST api is not documented.
I appreciate your thoughts on my thinking. It could be that I'm thinking about the problem in the wrong way.
Also, If anyone knows how to create a release using the REST api that would likely get me to where I need to be.
I see the REST api is to be documented at the following spot but is is not yet. I really want to get going, I have over 100 apps to deploy.
https://msdn.microsoft.com/en-us/library/vs/alm/release/managing-releases/create-release#CreateareleasebyusingtheRESTAPI
We also use TFS 2015 update 2 on-prem and use PowerShell to interface with TFS REST API.
As stated in comments on this thread the REST API documentation is live and to create a release refer to the following link: https://www.visualstudio.com/en-us/docs/integrate/api/rm/releases#create-a-release
To answer your question: - to create a release using a PowerShell script try the following:
$filePath = "C:\PATH_TO_JSON"
$username = 'DOMAIN\USRNAME'
$password = 'PASSWORD'
$body = Get-Content $filePath
$resource = "http://TFS_URL/_apis/release/releases`?api-version=2.2-preview.1"
$cred = New-Object System.Management.Automation.PSCredential($username, (ConvertTo-SecureString -String $password -AsPlainText -Force))
Invoke-RestMethod -Method Post -Uri "$resource" -Credential $cred -ContentType "application/json" -Body $body
The $filePath variable should point to a file containing the following JSON markup. Be sure to alter the variables within the example JSON to fit your on-prem Release Definition:
{
"definitionId": 12,
"description": "M 98 release",
"artifacts": [
{
"alias": "Fabrikam.CI",
"instanceReference": {
"id": "90"
}
}
]
}
You could also use JavaScript to interface with TFS REST API. See the post by #Elmar here: TFS 2015 REST API Authentication
The Release Management API docs for VSTS are live here. Most of the APIs should work for TFS 2015.2 also.
For creating a new release, refer to my earlier answer for the same.
You can retain a build indefinitely so it will always be available when you need it.
ReleaseManagement REST API got public at
https://www.visualstudio.com/integrate/api/rm/releases#Createarelease. Please have a look. While creating the release pass three things in the artifact :- alias, instanceReference (name and Id).
Related
We have two build YAML pipelines to run tests on TFS one for front-end and one for back-end tests. We use two self-hosted windows agents to run these builds and we are on Azure DevOps Server 2020. Ever since we started running the pipeline we noticed our TFS database size ballooning up. We've tried editing our retention settings to only keep the most recent builds but they are still saved no matter what we change.
Below are our retention settings:
Collection Settings
Project Pipeline Settings
Project Pipeline Release Retention:
EDIT: Test Retention Settings:
END EDIT
Our YAML pipelines don't have any specific retention settings so my understanding would be that it defaults to the project pipeline settings. However, this doesn't seem to be the case. We have runs that go as far back as November, which is when we first created the pipelines. I can also manually check which builds are and aren't retained:
Example of retained build
Example of not retained build
However, these runs are just never getting deleted. Is my understanding of how retention works just incorrect and the builds shouldn't be getting automatically deleted by TFS? Or do I need to change my Azure DevOps settings somehow to automatically delete the builds once the retention settings no longer apply to it?
It's also worth mentioning we do have a release pipeline, although we've been experiencing these problems since way before we created it and the release pipeline only has dependencies on master but no feature runs are getting deleted either.
I did find this SO post that seems to only apply to classic UI pipeline editor. Is there a way I can apply this to my YAML pipeline?
Edit 2
So I did make some more progress on this. I wrote a script that would delete all the runs that weren't held by retention settings:
$token = "{PAT}"
$url="https://{instance}/{collection}/{project}/_apis/build/builds/?api-version=6.0"
$token = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes(":$($token)"))
$response = Invoke-RestMethod -Uri $url -Headers #{Authorization = "Basic $token"} -Method Get -ContentType application/json
ForEach( $build in $response.value )
{
if ((-not $build.keepForever) -and (-not $build.retainedByRelease)) {
$url="https://{instance}/{collection}/{project}/_apis/build/builds/$($build.id)?api-version=6.0"
$deleteResponse = Invoke-RestMethod -Uri $url -Headers #{Authorization = "Basic $token"} -Method Delete -ContentType application/json
Write-Host "Deleted" $url
}
}
This deletes all the runs just fine. However, from what I can tell in the docs, this should happen automatically by TFS. Are there any event log sources I could filter for or any specific times of day to check that may lead me to where the actual deletion of the runs should be taking place?
It seems your problem was fixed in the Azure DevOps 2020.0.1 Patch 2 Release. I recommend looking at this thread in detail to see whether the solution applies in your case.
I am looking for an option, how to identify the version of artifact which is being stored in azure devops artifactory. Can someone please throw light on this.
Also i need to push artifact from 1 subscription (example ASubscrip) to another subscription (BSubscrip).
BSubscrip is obviously more strict in terms of security as PROD is being configured there, however our builds are done only on ASubScrip.
Hence I need to come up with a logic that if version available in BSubscrip is lower than version of ASubScrip, then only trigger the copy pipeline from ASubScrip to BSubScrip.
Please advise how it can be done via pipeline.
I was able to perform the operation with the help of below set of commands.
$response = invoke-RestMethod -Uri https://feeds.dev.azure.com/{Org}/{Project name}/_apis/packaging/Feeds//
The response would be json object and required property can be referred $response.versions.version
Please note that while reviewing the output of response object, my focus was only to retrieve version parameter and above approach helped me to get it.
Also note here TOKEN is PAT and there we need to perform some transformation as well.
$token = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes(":$($pat)"))
In TFS 2018 we were able to select multiple builds in the build results page.
After we upgraded to 2019, it seems we can no longer multi-select completed builds and perform an action on these, such as removing builds.
Can this still be done, or should this now be done using the API ? which would of course not be nice.
How to select multiple builds
I'm afraid this feature can not be done in azure devops 2019 now, also there's no directly api can let you get the feature e.g batch delete.
In fact, in TFS 2018, when you multi-select the builds and delete them, you could see the detailed progress from F12:
Actually, it executes the delete api in a loop to achieve the effect of a batch delete.
So, as a work around since there's no directly api to achieve such batch action, you can make use of foreach in powershell.
For example of batch delete,
DELETE https://{instance name}/{collection name}/{project name}/_apis/build/builds/{buildId}?api-version=5.0
You could make use the for loop with the powershell scripts into buildid(s) to delete them.
Simple delete script:
$url = https://{instance name}/{collection name}/{project name}/_apis/build/builds/{buildId}?api-version=5.0
Invoke-RestMethod -Uri $url -Method Delete -ContentType application/json
It is very straightforward to get all changesets, specific changesets, or even look a specific version of a file (given a changeset id) using not only the TFS API but the .NET client libraries.
However, what I can't seem to figure out is given the name/path of a file, and a specific branch, is how to retrieve the changeset history for that file.
I've tried using both the TfvcHttpClient as well as the raw TFS API (building my http GET request by hand) and I cannot seem to find a way to make this happen.
This is very similar to viewing a file's history in Visual Studio 2017:
I'm literally looking for a way via the TFS API to give me this information back.
Is this possible?
Thanks!
Rest API request:
{tfsurl}/{project}/_api/_versioncontrol/history"
In the request body:
{repositoryId: "", searchCriteria: "{"itemPath":"$/YourProject/YourFile","itemVersion":"T","top":50}"}
It will return the history for the itemPath from your body.
Sadly I struggle to find any documentation on this :/
I can not find any history request for tfvc here - Rest Api TFVC Version Control.
As workaround you can try to run tf.exe history and parse the output.
Depending on what API version you are using, here is the reference information for changesets.
https://learn.microsoft.com/en-us/rest/api/azure/devops/tfvc/changesets/get%20changesets?view=azure-devops-rest-5.0
the core url is:
GET {tfsurl}/{organization}/{project}/_apis/tfvc/changesets?api-version=5.0
You can also do this with TfvcHttpClientBase.GetChangesetsAsync and the ItemPath property of TfvcChangesetSearchCriteria
Here's an example in Powershell
$tfvcSearchCriteria = [Microsoft.TeamFoundation.SourceControl.WebApi.TfvcChangesetSearchCriteria]::new()
$tfvcSearchCriteria.FollowRenames = $true
$tfvcSearchCriteria.ItemPath = $ItemPath
$result = $TfvcHttpClient.GetChangesetsAsync($null, $null, $null, $null, $tfvcSearchCriteria).Result
Now that TFS 2015 comes with the same new Rest API of VS Team Services, I've taken a look at the API doc:
https://www.visualstudio.com/en-us/integrate/api/git/overview
One question naturally raised is that most queries do not expose an parameter for git branch or tag (e.g. download /path/to/my/file with tag 'release_v1.0'), which looks like a show stopper. As in my case, I need programatically pull out some source file under a certain branch/tag.
Is it not supported yet?
Yes you can. As or the link that you have above you can use the provided so to retrieve both branches and yes. In git they are really all the same thing, pointers. This use the "refs" api.
https://www.visualstudio.com/integrate/api/git/refs