I have a release pipeline that triggers when there's a PR to master. I want to be able to trigger a release from a build queue (so without creating a pull request).
The proces now is to manually queue a build of a specific branch (this is fine):
Now I have to manually release the branch as well:
I want to automate this proces.
Like I said my current automated release proces is only triggered when there's a PR for master:
Any suggestions how to trigger a release from a custom build action?
If you want to trigger a release from inside the build - you can use Azure Devops rest api for that. This is the rest api call you are interested in:
https://learn.microsoft.com/en-us/rest/api/azure/devops/release/releases/create?view=azure-devops-rest-5.0
you can use something like this to achieve that:
$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes("${user}:$(PAT_TOKEN)"))
$bearerAuth = #{ Authorization = "Basic $base64AuthInfo" }
Invoke-RestMethod POST https://vsrm.dev.azure.com/{organization}/{project}/_apis/release/releases?api-version=5.0 -Headers $bearerAuth -ContentType "application/json" -Body xxx
I think you can choose to add a source with Build as the artifact in Release, so you can trigger a release from a build queue without creating a pull request.The solution provided by 4c74356b41 is a good method, you can also try it.You can add a powershell task to the agent job of the build pipeline, and then write the script with the above rest api provided by4c74356b41 in the Inline script to run the build.
Hope this helps.
Related
I am trying to delete old branches which are x days old from Azure DevOps by using Powershell, but it is unsuccessful. Could you please help me out on this matter or if you have any better idea to execute this task, I am more than welcome to hear them out! I have been stuck with it for a few weeks now.
Thanks.
Deleting branches on Azure DevOps with Powershell
You could use the REST API to delete those Branch.
However, we do not recommend you to do this. It is not safe to use scripts to delete some old branches, because the script cannot determine whether the branch is important, but it is risky to delete based on the date. So you need to be clear about this before deleting.
First, we could use the REST API Refs - List to list all the branches for the Repo:
GET https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/refs?api-version=6.0
Then, we loop each branch with REST API Commits - Get Commits:
GET https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/commits?&searchCriteria.compareVersion.version=<YouBranchName>&api-version=6.0
And compare creation date or activation date, use the REST API to delete those branches:
POST https://dev.azure.com/{organization name}/{project name}/_apis/git/repositories/{repositoryId}/refs?api-version=5.1
Request Body:
[
{
"name": "{branchName}",
"oldObjectId": "{branchObjectId}",
"newObjectId": "0000000000000000000000000000000000000000"
}
]
Alternatively, if you want use git command line to delete, you could refer below document for some more details:
Deleting Old Local Branches With PowerShell
We are using azure devops for our CI/CD process. Many a times, in order to do some custom builds, we need to download the specific maven jar from artifact repo.
Is there a way (commandline or API) to do the same ?
Again the question is about download specific jar from azure artifacts.
Azure Artifacts - Download a specific version of maven artifact
The answer is yes. We could use the REST API Maven - Download Package to download the specific jar from azure artifacts:
GET https://pkgs.dev.azure.com/{organization}/{project}/_apis/packaging/feeds/{feedId}/maven/{groupId}/{artifactId}/{version}/{fileName}/content?api-version=5.1-preview.1
First, we need to get the feedId. We could use the REST API Feed Management - Get Feeds to get the feedId:
GET https://feeds.dev.azure.com/{organization}/{project}/_apis/packaging/feeds?api-version=5.1-preview.1
Note: The project parameter must be supplied if the feed was created in a project. If the feed is not associated with any project, omit the project parameter from the request.
For other parameters in the URL, we could get it from the overview of the package. Select the package and open the package, we could get following view:
Now, we have all the parameters, feedId, groupId, artifactId, version, fileName.
So, we could use the REST API with -OutFile $(Build.SourcesDirectory)\myFirstApp-1.0-20190818.032400-1.jar to download the package (Inline powershell task):
$url = "https://pkgs.dev.azure.com/<OrganizationName>/_apis/packaging/feeds/83cd6431-16cc-480d-bb4d-a213e17b3a2b/maven/MyGroup/myFirstApp/1.0-SNAPSHOT/myFirstApp-1.0-20190818.032400-1.jar/content?api-version=5.1-preview.1"
$buildPipeline= Invoke-RestMethod -Uri $url -OutFile $(Build.SourcesDirectory)\myFirstApp-1.0-20190818.032400-1.jar -Headers #{
Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
} -Method Get
Since my maven feed is an organization scoped feed, I omit the project parameter from the URL.
The result:
I've found this way:
Open feed page in Azure, click Connect to feed
Choose Maven, copy the URL from Project setup > repository/url of the pom.xml sample.
That should look like:
https://pkgs.dev.azure.com/YOUR-ORGANIZATION/_packaging/YOUR-FEED-NAME/maven/v1
Append the artifact info to that link:
https://pkgs.dev.azure.com/YOUR-ORGANIZATION/_packaging/YOUR-FEED-NAME/maven/v1/ch/qos/logback/logback-classic/1.2.3/logback-classic-1.2.3.jar
Hint: compare it to the one from maven repository:
https://repo1.maven.org/maven2/ch/qos/logback/logback-classic/1.2.3/logback-classic-1.2.3.jar
I am trying to setup azure pipelines to trigger a build on every PR update, and a release on every merge. For a couple of reasons when the PR is merged, i need to access data saved by the latest validation build of the PR.
However to do that i need the PRid during the run of the Release pipeline. How can one achieve that?
From the release you can retrieve the commit Id which triggered the build.
Then you search for the commitId in the list of completed PRs and retrieve your PR number.
$commitId = "$(RELEASE.ARTIFACTS.{YOURARTIFACTALIAS}.SOURCEVERSION)"
$repoId = "$(RELEASE.ARTIFACTS.{YOURARTIFACTALIAS}.REPOSITORY.ID)"
$pullRequestsUri = "https://dev.azure.com/{organization}/{project}_apis/git/repositories/" + $repoId + "/pullrequests?searchCriteria.status=completed&api-version=5.1"
$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f "", "$(System.AccessToken)")))
$pullRequests = Invoke-RestMethod -Uri $pullRequestsUri -Method GET -ContentType "application/json" -Headers #{Authorization = "Basic $base64AuthInfo" }
foreach ($value in $pullRequests.value) {
if ($value.lastMergeCommit.commitId -eq $commitId) {
$pullRequestId = $value.pullRequestId
}
}
Write-Host $pullRequestId
Based on your scenario, to my knowledge, it is complex to get related build information in your release. Besides, it may cause unexpected result if not cover all possible scenarios.
I'd suggest that you could refer to these steps blow:
Remove publish build/pipeline artifact or unnecessary tasks, just remain tasks for validation, which will save a lot of time. (Because, in general, the validation build will be triggered too many times, waste too much time to publish useless artifact or other data)
Create a new build pipeline and enable Continuous integration for target branch (e.g. master)
Add publish build/pipeline artifact task
Edit release pipeline and link this build pipeline and enable Continuous deployment. (Could add additional filters)
With this way, after completing the pull request, this new build pipeline will be triggered and will publish necessary artifact, then the release will be triggered.
For pull request validation builds, they just do tasks to validate the code (e.g. build project), but not publish artifact.
Simple scenario for saving time:
A pull request has 50 validation builds
old way: publish artifact of each takes 1 minutes, then total time is 50 minutes
new way: the new pipeline do tasks for build and publish, it just run once and may just takes 10 minutes.
Then you can save 40 minutes.
In Release Pipeline, you could use the variable $(RELEASE.ARTIFACTS.<<Source alias name>>.PULLREQUEST.ID) to get the Pull Request ID.
Note: the Source alias name is the name set in the release artifacts.
By the way, if you use a default variable in your script, you must first replace the . in the default variable names with _.
For example: $env:RELEASE_ARTIFACTS_<<Source alias name>>_PULLREQUEST_ID
Here is a doc about the Release variables.
Hope this helps.
I have a requirement to get the build artifact name in release? I dont see a predefined release variables which can get this. Is there a way to fetch this?
If you mean you want to get the Artifact Name which is defined in Publish Build Artifacts task in Build process (By default it's Drop), then you can run below PowerShell script calling the REST API to retrieve the value and set a variable with logging command. After that you can use the variable in subsequent tasks...
Enable Allow scripts to access the OAuth token in Agent Phase
Add a PowerShell task to run below script
$url = "$($env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI)$env:SYSTEM_TEAMPROJECTID/_apis/build/builds/$env:BUILD_BUILDID/artifacts?api-version=4.1"
Write-Host "URL: $url"
$pipeline = Invoke-RestMethod -Uri $url -Headers #{
Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
}
Write-Host "artifactName:" ($artifactName = $Pipeline.value.name)
#Set Variable $artifactName
Write-Host "##vso[task.setvariable variable=artifactName]$artifactName"
#Then you can use the variable $artifactName in the subsequent tasks...
This is kind of a hack/kludge, but if you name your Release to be the same as the package you are releasing, you can get the name from the variable
$(Release.DefinitionName)
So if your build creates a package called My.Cool.Package in a build pipeline called my_cool_package, that ends up being aliased in the release pipeline as _my_cool_package.
Naming the Release pipeline the same as the package (My.Cool.Package) allows you to access the package and files within it (for doing XML and JSON transforms for example in other tasks) by using
$(System.DefaultWorkingDirectory)/$(Release.PrimaryArtifactSourceAlias)/$(Release.DefinitionName)
This is well-documented under the sections General Artifact Variables and Primary Artifact Variables.
The primary artifact name is Build.DefinitionName.
I have connected Visual Studio Online to my Azure website. This is not a .NET ASP.NET MVC project, just several static HTML files.
Now I want to get my files uploaded to Azure and available 'online' after my commits/pushes to the TFS.
When a build definition (based on GitContinuousDeploymentTemplate.12.xaml) is executed it fails with an obvious message:
Exception Message: The process parameter ProjectsToBuild is required but no value was set.
My question: how do I setup a build definition so that it automatically copies my static files to Azure on commits?
Or do I need to use a different tooling for this task (like WebMatrix).
update
I ended up with creating an empty website and deploying it manually from Visual Studio using webdeploy. Other possible options to consider to create local Git at Azure.
Alright, let me try to give you an answer:
I was having quite a similar issue. I had a static HTML, JS and CSS site which I needed to have in TFS due to the project and wanted to make my life easier using the continuous deployment. So what I did was following:
When you have a Git in TFS, you get an URL for the repository - something like:
https://yoursite.visualstudio.com/COLLECTION/PROJECT/_git/REPOSITORY
, however in order to access the repository itself, you need to authenticate, which is not currently possible, if you try to put the URL with authentication into Azure:
https://username:password#TFS_URL
It will not accept it. So what you do, in order to bind the deployment is that you just put the URL for repository there (the deployment will fail, however it will prepare the environment for us to proceed).
However, when you link it there, you can get DEPLOYMENT TRIGGER URL on the Configure tab of the Website. What it is for is that when you push a change to your repository (say to GitHub) what happens is that GitHub makes a HTTP POST request to that link and it tells Azure to deploy new code onto the site.
Now I went to Kudu which is the underlaying system of Azure Websites which handles the deployments. I figured that if you send correct contents in the HTTP POST (JSON format) to the DEPLOYMENT TRIGGER URL, you can have it deploy code from any repository and it even authenticates!
So the thing left to do is to generate the alternative authentication credentials on the TFS site and put the whole request together. I wrapped this entire process into the following PowerShell script:
# Windows Azure Website Configuration
#
# WAWS_username: The user account which has access to the website, can be obtained from https://manage.windowsazure.com portal on the Configure tab under DEPLOYMENT TRIGGER URL
# WAWS_password: The password for the account specified above
# WAWS: The Azure site name
$WAWS_username = ''
$WAWS_password = ''
$WAWS = ''
# Visual Studio Online Repository Configuration
#
# VSO_username: The user account used for basic authentication in VSO (has to be manually enabled)
# VSO_password: The password for the account specified above
# VSO_URL: The URL to the Git repository (branch is specified on the https://manage.windowsazure.com Configuration tab BRANCH TO DEPLOY
$VSO_username = ''
$VSO_password = ''
$VSO_URL = ''
# DO NOT EDIT ANY OF THE CODE BELOW
$WAWS_URL = 'https://' + $WAWS + '.scm.azurewebsites.net/deploy'
$BODY = '
{
"format": "basic",
"url": "https://' + $VSO_username + ':' + $VSO_password + '#' + $VSO_URL + '"
}'
$authorization = "Basic "+[System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($WAWS_username+":"+$WAWS_password ))
$bytes = [System.Text.Encoding]::ASCII.GetBytes($BODY)
$webRequest = [System.Net.WebRequest]::Create($WAWS_URL)
$webRequest.Method = "POST"
$webRequest.Headers.Add("Authorization", $authorization)
$webRequest.ContentLength = $bytes.Length
$webRequestStream = $webRequest.GetRequestStream();
$webRequestStream.Write($bytes, 0, $bytes.Length);
$webRequest.GetResponse()
I hope that what I wrote here makes sense. The last thing you would need is to bind this script to a hook in Git, so when you perform a push the script gets automatically triggered after it and the site is deployed. I haven't figured this piece yet tho.
This should also work to deploy a PHP/Node.js and similar code.
The easiest way would be to add them to an empty ASP .NET project, set them to be copied to the output folder, and then "build" the project.
Failing that, you could modify the build process template, but that's a "last resort" option.