0
votes

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.

1

1 Answers

1
votes

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.

  1. 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.
  2. 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.