Our PR environment deployment gets cancelled when new changes are pushed to the PR. I'm trying to prevent this but unable to find where it's determined.
The PR environment deployment is set up as an optional branch policy on our main branch. This kicks off the build pipeline on the PR branch which produces an artifact that then triggers the PR environment deployment. The PR build deployment is manually triggered.
PR job pre-deployment condition is set for "Pull request deployment" and Triggered on "After Release" of the Build artifact. On the pipeline, continuous deployment is enabled with Pull request trigger enabled.
It's interesting to note that the PR build is not cancelled by changes pushed and that pushing changes during the build doesn't prevent the deployment from running. It's just that once the deployment is triggered, it's immediately cancelled when changes are pushed to the PR branch.
By following this doc: Deploy pull request Artifacts with Azure Pipeline, we can set up Build validation and Status Checks
for main branch, and new pull request will trigger a new build and then trigger a new release. And we can see the same issue that once the deployment is triggered, it's immediately cancelled when changes are pushed to the PR branch.
By reference to this doc: Configure a branch policy for an external service, we can explain this scene out of the following considerations.
Before the introduction of pull request release triggers, when a PR was raised, you could trigger a build, but not a deployment. Pull request triggers enable you to set up a set of criteria that must be met before deploying your code. Thus deployment is an important operation, new changes are pushed during deployment means there are issues or something else, so Azure DevOps cancels this ongoing deployment and creates a new one to check the policy.
When the service has posted status, the policy will update accordingly. Completion will be blocked until the policy approves the PR. Thus new changes mean there should be new check/release, so Azure DevOps cancels this ongoing deployment and creates a new one to check it.
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:
We are using Azure devops with the workflow for each task as:
Task branch to Release branch
Then Release branch to master
The reviewer will approve each pull request.
However, a user creating a PR can also create one from task branch directly to master.
Is there any way, by policies/validations that the system can prevent creation of the PR itself, which is from task to master.
Currently azure devops doesnot have the policies/validations to prevent creating a pr which is task to master.
However, there is workaround to prevent merging the PR which is task to master.
You can create a pipeline with a script task to check the source branch of the PR. See below:
$sourceBranch = "$(System.PullRequest.SourceBranch)"
if($sourceBranch -ne "refs/heads/release")
{
exit 1
}
For example add a powershell task with above script. The script will check if the PR source branch is release branch, and fail the pipeline if it is not.
Then you can add above pipeline to the branch policy of master branch. See below:
Then any PR which is not release to master will fail to be validated and cannot be completed. (But it still cannot prevent creating a PR from test to master)
You can also click here to submit a feature request(Click Suggest a feature and select Azure Devops. ) to Microsoft development team. Hopefully they will consider adding this feature in the future.
See below screenshot from my test pipeline.
If you only want a subset of users to manage the merge to master, you can setup branch security on the master branch that prevents contributing to pull requests that would target that branch.
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.
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.