How Can I automatically reject pull requests in Azure devops when a build has failed? I wont see any pull request in azure if build is not succeed.i want to write a command for it in yamel file.
As far as I know it is impossible to have the PR automatically rejected on a failed build but you can configure it so that the PR cannot be merged in until it does pass a build.
This is done by adding a build validation step in the branch policies. Documentation can be found here
Related
We use Azure DevOps for our CI/CD pipelines, but our repositories are in GitHub. We currently trigger the CI pipelines on each push, but there is no link to GitHub so we lose easily seeing the status of a build in pull requests / automatically failing a check if a build fails.
Azure Pipelines has an app on GitHub Marketplace for integrating pipelines with repositories / pull requests. I installed this in our GitHub organization and configured it with the repository access it needs, which then had me authenticate with Azure DevOps, select the project and the pipeline yaml associated with the repository.
This works great and I can see the status directly in a pull request -
The issue is that I have multiple pipelines I would like to run and display the status of in the pull request. We have a monorepo but I only want to build an app if it was modified, so I utilize path filters in the Azure Pipelines yaml so the CI is only run when I need it to. GitHub does not discover/display the status of other CI pipelines I have in the project.
Initially, I tried just setting up another azure pipelines yaml that is triggered by pull requests. When I make a pull request, I see in Azure Pipelines the CI was triggered by 'PR automated for {pr number}', but it does not display it's status in GitHub.
I ended up going to the Azure Pipelines app settings in GitHub, 'revoking' access to the repository, and then immediately re-configuring it with access to the same project as before, but selecting a different pipeline yaml. This worked, it retained the first build I configured and added the second, and now multiple builds are shown in the pull request -
But this does not seem like the intended way to accomplish this. The GitHub app links to the entire documentation for Azure Pipelines, not specifically to docs about the app, and I have not been able to find any info within on how to do this.
Is there a way to add multiple pipelines with the Azure Pipelines app on GitHub, outside of this workaround?
In past I was running my pipelines in Jenkins, where in branch discovery strategy was set to
Merging the pull request with the current target branch revision
This allowed for PR to be build as close to target branch as possible. I just noticed that azure devops pipeline seem to be not doing this, building the branch as is instead. Even thought I get notyfication when there are conflicts, etc so its testing it but not using it to validate the build, Is there some kind of property / configuration for that or would I have to implement it manually?
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
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 have a repo which has two branches:
develop (repo's default branch)
master
Code within the develop branch is known to be releasable as an "alpha" version, while code within master is known to be production ready.
Currently, the develop branch's policies requires that a CI build must successfully complete for the PR to merge. That build will create NuGet package artifacts with a prerelease tag (alpha-####).
A release pipeline is responsible for taking these packages and publishing them to an internal NuGet feed.
What I'm trying to achieve is to have the release pipeline triggered automatically when the PR is completed, not whenever the CI build succeeds.
I expected the "pull request trigger" to do just that, but much to my surprise the trigger won't acknowledge the PR's status and have the release pipeline start as soon as the CI build is completed.
This means that if the PR gets rejected for whatever reason, a NuGet may still be deployed to my feed!
What am I doing wrong here? How come the pull request trigger doesn't work any differently than the continuous deployment trigger? What's it's purpose then? :/
The continuous deployment trigger means, if you specify certain types of artifacts in a release pipeline, you can enable continuous deployment. This instructs Azure Pipeline to create new releases automatically when it detects new artifacts are available.
The Pull request trigger means, once a pull request release is configured, anytime a pull request is raised for the protected branch, a release is triggered automatically, deployed to the specified environments.
So these two triggers are different and more detailed information you can refer to here.
https://learn.microsoft.com/en-us/azure/devops/pipelines/release/deploy-pull-request-builds?view=azure-devops
https://learn.microsoft.com/en-us/azure/devops/pipelines/release/triggers?view=azure-devops
And if you still want to deploy your Nuget after a PR completed, I recommend you to create a new build pipeline and enable the Continuous integration for it. Then set this build pipeline as the Release pipeline Artifact.
Because when a PR completed, it will create a new commit to the target branch and this new commit will trigger the build pipeline, and the build pipeline will trigger the release pipeline to deploy the Nuget as your expected.
Not sure if anyone's still looking for a solution to this over a year after the fact, but I was so I wrote an Azure Function app to receive pull request close webhooks from DevOps and translate those events into new releases.
You can find it here on my github: https://github.com/GravlLift/OnPullRequest
Feel free to fork it to fit whatever your individual needs are.