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.
Related
I've got a Azure Devops project that's deploying to an app service that has a workflow that looks like this:
On PR creation, build gets triggered.
Build kicks off a CD pipeline to deploy app service to a staging slot
Stage 2 of the CD pipeline is swap staging and prod. This requires an approval
PR Still needs to get completed manually
The reason I wanted to build it this way was so that anyone pushing changes to the repo could validate them in the staging slot in the live environment before they went into prod. The flow seems to work, except that there are two things to do at the end of a change. The approver must approve the swap to prod task in the pipeline, and the associated PR must be completed. I've found cases where the PR never gets completed, which means that you end up with unmerged changes.
Is there a way that I can have the release pipeline (which is triggered off a PR build) complete the associated PR as part of a release stage? I'd like to make sure that what gets merged into the main branch is the current code, so I'd rather not change it to trigger on PR completion because at that point things are already merged, and a breaking change would have to be undone. The other way I figure I could handle it would be to:
On PR Creation, trigger a validation build, and a release pipeline to deploy to the dev slot.
On PR completion, trigger a release pipeline to deploy the PR build to prod.
This would change the approval flow a little, but might be better at making sure that the PR gets completed properly.
I actually ended up coming up with a different flow for this. What I got working was:
Create PR for feature branch
PR creates build
Staging release pipeline triggers off PR, and deploys to a staging slot
Changes can be validated in staging
PR completion merges to main branch
Merge to main triggers a CI build pipeline
CI build triggers a release pipeline that goes to the prod slot
This means that the PR must be completed in order to release to prod. It does mean that the build that goes into prod isn't necessarily the same one that's in staging, but it's built from the same code, so that should be identical.
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:
In my Azure DevOps pipeline, when a PR (from feature branches to dev branch) or a direct push against the dev branch (DevOps engineer has 'force push' privileges) occurs, a CI build automatically gets triggered. As soon as the build finishes, a CD pipeline starts (continuous integration enabled).
Is there a way from the CD pipeline (PowerShell) to detect if the CI build was triggered from a PR or a direct push?
RELEASE_REASON says Manual or ContinuousIntegration which does not help in my case.
Using the REST API to get the build details says "reason": "individualCI" which does not help neither.
You can use this rest api to get the reason of the build trigger:
GET https://dev.azure.com/{organization}/{project}/_apis/build/builds/{buildId}?api-version=5.1
I test with post man ,if the cause of the build is CI, the reason of the build will be individualCI
If the cause of the build is pull request, the reason of the build will be pull request.
Note that if you enable continuous integration and set the pr trigger build in the branch policy, then when you create a pr to trigger build, the build pipeline actually runs two builds, one triggered by creating PR, the other is the ci build triggered by the change of the target branch after the pr is completed.
I have set up a pull request release trigger in the following way.
I want to deploy Artifacts from VerifyApiTestEnvironment branch whenever pull request into that branch is successfully completed.
This is how my artifacts look.
This is how my CD trigger looks like.
This is how my pre-deployment conditions look like.
This is how my policy screen looks.
This is how my branch structure looks. I am always getting an error in the build saying source branch missing the changes from master when I complete the pull request targeting the VerifyApiTestEnvironment branch. What could be the reason behind this?
Every time I am committing my changes to a featureBranch and then I open a pull request for it to merge into VerifyApiTestEnvironment branch.
I expect to trigger a release and then a deployment every time I do this, but the release is not getting triggered.
Am I missing something related to configuring PR triggers?
The setting of yours has some problem. As Daniel said, it is used to set as deploy with a PR created. In addition, if you want to deploy just after PR is completed, the source of this release should be Repository instead of build pipeline.
So, first, you need to change your release source as Azure Repository:
And then, enable Continuous deployment trigger. While the PR completed, it means that code change are merged into the target branch of Repository. So, this need to be enabled, or the deploy will not be triggered while the PR is completed.
In addition, you need to set branch filter, or the deploy will be triggered no matter which branch is changed. Here I set just merge into master branch( PR target branch is master) can trigger this CD.
For this option, it just be use for the PR created trigger deploy. Since you just want deploy triggered by the PR completed, so you do not need enable it.
Now, if your master has policy that the code change applied successfully only after PR created and verified, the CD will be executed only after PR completed.
For some configuration of policy, build policy is used to set build trigger, and status policy used to trigger the release.
So, according to your policy setting, it's used to trigger the build first, and then the build will trigger the release. It's not directly trigger the deploy just after the PR completed.
So I have a application split in 4 different repositories which all have their own Azure Pipeline build. But the artifacts of these 4 builds are deployed in one release (into one application).
On a check-in (pull request merge) on our development branch in one of the repos, a build for that repo is started. When this build completes, a release is triggered with the newly finished build artifact + 3 older artifacts based on the "Latest from the build pipeline default branch with tags" from the other repos. So always the latest builds from the development (dev) branch.
Now we want to also deploy an environment for every pull request that is created in the different repos, so our business can test a pull request.
I have the release pipeline done (the actual deploying of the environment), but not sure how to select the artifacts correctly. After a build on a pull request branch, I need to start a release with the pull request artifacts from that triggering build + the latest dev branch artifacts from the other 3 builds.
Manually I can start a new release, by default it selects all the dev artifacts, but by hand I can select the correct artifacts for the PR branch and start a correct deployment. But I want to automate (trigger) this.
How can I configure this automated trigger? Could I use tags? Or am I thinking about this in a wrong way?
Edit
I ended up setting this up by using 4 different stages which have different artifact filters. A stage for each artifact. For that artifact we allow dev_* and all other artifacts need to be from dev_. That way the correct stage is triggered for each artifact trigger, selecting the feature branch and dev branch for others.
It is not the ideal solution, because it does require some duplication of code, but by using Task Groups I have been able to minimize this. But for now I don't see a better solution.