I'm using azure for a windows app and so I don't really need to go as far as CD as that isn't really relevant. We eventually plan to move to the cloud but for now that is not the case.
I have now got my .net (c#) build running as a build pipeline and I have a develop branch which Pull Requests are used to merge in changes. What I want is for a tester to be able to pick up the build artefact that was created for a particular bug or product backlog item when the pull request was successfully completed. Is this possible without having a Release Pipeline? I don't currently have a subscription that would allow me to create a release pipeline.
How can I access the artefact from a pull request for which a build was run?
Indeed, just as Lucas said, if we are starting from the pull request to solve this problem, it is really difficult. But we could try reverse thinking to start with the build pipeline.
Azure devops provided us some predefined variables, like Build.BuildId, System.PullRequest.PullRequestId.
So, we could use the REST API Pull Requests - Update in the build pipeline to update the comment with the link to the artifact.
PATCH https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/pullrequests/{pullRequestId}?api-version=5.1
Since the current build is triggered by a pull request, we could use the predefined variable System.PullRequest.PullRequestId to get the pullRequestId directly.
Now, we just need to get the link of the artifact, we could use the Artifacts - Get to get the artifact info:
GET https://dev.azure.com/{organization}/{project}/_apis/build/builds/{buildId}/artifacts?artifactName={artifactName}&api-version=4.1
We could get the buildId by the predefined variable Build.BuildId, then we will get the download URL:
So the idea of summing up my solution is to use REST API Pull Requests - Update in the build pipeline to update the comment of the pull request, which contains the download path of the artifact.
Note: You could also add custom conditions in the REST API task in the build pipeline:
and(succeeded(), eq(variables['Build.Reason'], 'PullRequest'))
So, with this setting, only the build triggered by the pull request will execute this rest api task.
Hope this helps.
The pull request build that you defined can publish artifacts, see this documentation to see how to do it.
Once those artifacts are published, your tested can browse/download them on the build run page (click on header pa> "Related" > click on "#number of artifacts you publish# published").
Alternatively, you could add a task to copy your artifacts to an Azure Blob Storage, but that would require more configuration.
One can find build id with branchName filter :
GET https://dev.azure.com/{organization}/{project}/_apis/build/builds?api-version=5.0&reasonFilter=pullRequest&definitions={buildDefinitionId}&branchName=refs/pull/{pullRequestId}/merge
Once builder id has been retrieved, get artifact by name :
GET https://dev.azure.com/{organization}/{project}/_apis/build/builds/{buildId}/artifacts?artifactName={artifactName}&api-version=6.0
Related
trying to rename the pipelines build and release through REST API, I have gone through the official Microsoft documentation but didn't find any API's for this task. Did i miss any or we have such API's where by using build id/build name we can rename the pipeline
have you tried to make the change in the azure release page and look at the request that is being sent in the dev tools network tab? A couple of months ago I was able to learn how to retrieve some information that I was looking for by doing that.
Best regards.
You could use Definitions-Get API to retrieve the requested body by pipeline definition ID.
Copy the response as body and use Definitions-Update to rename the pipeline. Update the pipeline name of this revision.
Check the DevOps UI output.
The above workflow also applies to release pipeline, your need to change the REST API.
Using Releases-Get release to get the latest revision and using Releases - Update Release to rename it
I checked several sources, seems possible, but can't get it work.
What I want is that whenever a PR is created and PR build is successful, then a PR release is run and a site is created (either with PR Id or PR source branch, e.g. pr122--xxx.azuresite.net).
From an answer for this question,
Looks like I could use release.artifacts.alias.PULLREQUEST.ID, but when I tried it, this doesn't work at all. Also from the official doc, there is no mention of this variable. Is this only for the new YAML pipeline?
As most of our things are in classic pipeline, the solution I can think of is to parse the build source, which is refs/pull/11201/merge. Looks like 11201 is the Pull Request ID, so I just need to replace refs, pull,merge and "/". But I am not sure if better approaches available.
Following this doc: Deploy pull request Artifacts with Azure Pipelines, we can successfully create a pull request deployment by choosing Azure Repos as the source artifact.
If one pull request is created, a new release will be triggered. And as you have found, the source branch of build source is "refs/pull/{PullRequestId}/merge", so you are right.
In addition, if you set the Azure Repos as the primary artifact, we can get the pull request branch by using the predefined variable Release.Artifacts.{alias}.SourceBranch. In below example, we can use the PowerShell task to run below command.
Write-Host "Release.Artifacts._215.SourceBranch: $(Release.Artifacts._215.SourceBranch)
See: Default variables - General Artifact for details.
With the classic build pipelines and classic triggers, it was easy enough to track builds that were triggered by completion of other builds by just polling for builds requested by the same user.
Now, with resource triggers, the requested by property switching to the build service account instead of the original author of the triggering commit.
I have been going through the documentation to try and find another way to see triggered builds from the original build ID but have not found anything.
There is an "Associated Pipelines" tab on the build summary page that at least has the pipelines containing the triggered builds, but I cannot find anything to get that by API either.
According to your description, you can first call the REST API to get all the running build pipelines in the definition, and then use the powershell script to loop check the id in the parameter triggeredByBuild in the request body in the specific build so that you can see triggered builds from the original buildId.
Note: The id marked in the attachment is the original buildId that triggered another build pipeline.
I am not able to trigger a pull request release by creation of a pull request.
Please check what I am doing wrong.
First I set a Pull request trigger to Enabled for the required artifact.
Then I enable Pull request deployment for Testing stage
The latest build run is successful for the source pipeline:
But when I create a pull request (either manually or programatically as a final step in the source build pipeline), a new release is not triggered.
Thanks in advance for your help.
From your screenshot, your build is triggered manually, you need to set a branch policy for the master branch to make the build triggered by pull request.
This is because you select build as the artifact source type. If you choose azure repo as source type, you do not need to set this branch policy.
Here is a document you can refer to .
I want TeamCity to build all pull requests to specific target branch, e.g. develop.
So, I want to build following pull requests:
develop...foo_branch
develop...bar_branch
and skip this:
master...foo_branch
master...bar_branch
In TeamCity I can define branch specification to build all pull requests:
+:refs/pull/*/head
or define filter by source branch:
-:refs/heads/(spikes-*)
But I need filter by target branch. Is it possible?
I've written a script to work around this issue. It can be run as one of the first build steps in TC's build configuration. The script will ask for pull request details from Github, parse the response and inject source and target branch names as TeamCity parameters and environment variables. In the next build steps, you'll be able to abort the build or do whatever else you need based on these variables.
https://gist.github.com/dzzh/a6d8631e9617777fb5237bc9ec7b356b
For the script to work, you'll have to submit PR's id as a command-line argument. We use the recommended refspec (refs/pulls/*/head) to run our builds, I extract the PR id from it and invoke the script with it.
Currently it's not possible to differentiate pull request branches based on their target branch in TeamCity. Please watch/vote for the request https://youtrack.jetbrains.com/issue/TW-43759 which is planned for the upcoming release.
Build Feature: Pull Request
Pull request support is implemented as a build feature in TeamCity. The feature extends the VCS root’s original branch specification to include pull requests that match the specified filtering criteria.
To configure the pull requests support for a build configuration, go to Build Configuration Settings | Build Features, click Add build feature, and select the Pull Requests feature from the dropdown list in the dialog.
Source: https://blog.jetbrains.com/teamcity/2019/08/building-github-pull-requests-with-teamcity/
So the filtering is done with the Build Feature: Pull Request, where By target branch: should be set to the targetet branch for example refs/head/master or refs/head/myspecialbranch