We have 3 repos in Azure DevOps. We use Azure Pipelines to run our CI/CD chain.
Repo A is a toolset used by the other repos.
Repo B uses A as submodule, and C uses A as git submodule.
When creating a PR in repo A, we want to trigger test Pipelines in repo B and C and have the status in repo A's PR. B and C's pipelines/runs should use the PR commit when running their tests. This to avoid that changes in repo A breaks repo B and C upon release.
Our problem is that we want to make sure to use the right commit of repo A (the one in the PR) and to get the test results for repo B and C in to the PR.
This should be possible through build-validation policies in a branch policy, but it won't be straight forward.
Under the hood, when you specify a build in the build-validation policy, azure-devops will queue the pipeline on a temporary branch /refs/pull/<id>/merge. It queues the pipeline with several additional variables that represent pull request meta-data. When that build completes, it sends a status message back to pull-request to indicate whether the conditions were met.
Microsoft has a few articles on how to create a custom PR server or using a Function App to create custom branch policies. These could be used as an approach, but both articles suggest that they invoke based on a webhook when the pull request is created. Both articles mention how to send custom PR Status messages back to the PR.
If you want more control over manually re-queueing the build-validation, you could in theory also create a pipeline that triggers the other pipelines in the other repos.
Define a build-validation pipeline that can be used to trigger the other pipelines. This is equivalent to using a Webhook/Function app, but the main difference is the UI in the Pull Request provides options to retrigger the build.
This build-validation pipeline reads the queue-time variables to identify which PR is being executed. You can add logic to this pipeline to use the Azure DevOps REST API to queue the pipelines in the other repos/projects. When queuing these pipelines, pass the details of the pull request meta-data as queue-time variables in the body of the message.
When the external pipeline runs, read the queue time parameters to record which PR initiated the build. Add some custom logic to include checking out the /refs/pull/<id>/merge branch for your submodules then Build + Test.
When the external pipeline completes, post the PR Status back to the originating PR.
Modify the branch policy to indicate the Build Status from the other pipelines as Required.
Related
I've been migrating build/release pipelines in Azure DevOps to the unified YAML format. Everything works as expected apart from the work items which are associated with CI builds once a PR is merged to the master branch. Here is the workflow:
Developer raises PR to merge changes from feature branch into the master branch
The PR has a build policy which executes the YAML pipeline against a test environment
The PR is completed and the feature branch is merged into the master branch
The YAML pipeline has a CI trigger for deployments to higher environments
For step 2 the triggered build shows whichever work items are associated with the PR:
However, for Step 4 the triggered CI build lists all work items in the master branch rather than just those associated with the PR:
Is there a way to only associate the work items which are associated with the PR to the CI build which is triggered once the feature branch is merged into master?
I can reproduce this issue and I found a similar ticket, they have reported it, you could follow this ticket to get the latest news.
If the build status is queue or running, then we create a new build, the new build will contain before build link work item. This is why the step 4 the triggered CI build lists all work items in the master branch rather than just those associated with the PR.
If all builds are completed, then we complete the pull request to trigger the CI build, it will be associated with the expected work items.
When all the builds were completed, I merged the PR to trigger the CI build, it just contain the pull request link work item.
Test result
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.
My goal is to block a PR completion until a change has gone through a CI pipeline and been deployed in a test release pipeline successfully. Additionally, I want to control which CI pipeline builds enter the release pipeline, so release entries don't get added with every PR commit.
I currently have the CI pipeline setup and working and I have a release pipeline working with manual additions.
To solve my problem, I tried to modify the Release pipelines Build Artifacts settings to use Pull request triggers for a specific target branch. Then, in the Release pipeline stage's pre-deployment conditions, I've selected a trigger of "After release" with pull request deployment enabled. However, I'm not seeing releases automatically created.
Is what I want possible? Are there other steps to execute this?
How can I block PR completion until a release succeeds in Azure DevOps?
To achieve this, you could add the release pipeline as Status Checks in the Branch Policies:
Detailed steps:
Add the CI pipeline as Build Validation in the Branch Policies for the specific target branch.
Do the same release pipeline settings as you, enable Pull request triggers for the specific target branch and enable pull request deployment.
Add the release pipeline as Status Checks in the Branch Policies for the specific target branch.
Note:
If you could not see the release pipeline in the list when you add
the Status Checks:
Please try to change the Source type of the release from Build Artifacts to Azure devops repos for the specific target branch, and also enable Pull request triggers for the specific target branch. Then, create a pull request to trigger this release pipeline. After that, we refresh the Branch Policies, we will see the release pipeline.
Now, we change the Source type of the release back to Build Artifacts and enable Pull request triggers for the specific target branch and enable pull request deployment.
The reason why you did not see releases automatically created may be that your build pipeline is not triggered by PR (maybe manually).
Mytest result :
If I do not set the release pipeline as Status Checks, just enable Pull request triggers and pull request deployment, it will set as Optional, it will not block PR completion:
If I make a pull request in ADO from one of my branches then any commits I push to my branch automatically trigger the build pipeline:
This is configured in the build validation branch policies on master:
But for draft pull requests I need to trigger builds manually:
The documentation (here) does not mention any distinction between active and draft pull requests. How do I configure my project so that commits to branches in a draft pull requests automatically trigger a build?
According to the docs:
Draft pull requests do not include reviewers or run builds by default
but allow you to manually add reviewers and run builds. To promote the
pull request to a normal pull request, simply click the Publish button
from the pull request detail page.
So, it looks like you experience the expected behavior.
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.