Prevent Pull Request builds from triggering Continuous deployment trigger Azure DevOps Server Prevent Pull Request builds from triggering Continuous deployment trigger Azure DevOps Server powershell powershell

Prevent Pull Request builds from triggering Continuous deployment trigger Azure DevOps Server


We've established that there is no "best solution" for this problem at the moment, below are some alternatives.

Easy work arounds

  • Unlink your current PR Policy build definition from release definition and create new build definition (or clone exiting). Link this new build definition to your releases and run it manually.
  • Remove Continuous deployment from your release definition and create your releases manually from your completed builds.
  • Use continues deployment and set it to some branch. Then your deployment will trigger only after completing of PR (if you set CI for your build).

enter image description here


Release variables and custom conditions (single artifact)

If you only have a single artifact in your release, you can skip tasks on the job level by using the Build.SourceBranchName release variable:

enter image description here

When the variable expression resolves, if the Build.SourceBranchName variable is equal to merge it skips all following tasks:

enter image description here


Release variables and custom conditions (multiple artifacts)

Finally, if you're using multiple artifacts in your release, you can still accomplish the above behavior, albeit, you need to do some extra work with a PowerShell script.

You use a PowerShell script to look at the RELEASE_TRIGGERINGARTIFACT_ALIAS environment variable and then looks at the corresponding RELEASE_ARTIFACTS_<RELEASE_TRIGGERINGARTIFACT_ALIAS>_SOURCEBRANCHNAME variable.

Your environment variables (visible in the Initialize Job step of a release look like the following.

...[RELEASE_ARTIFACTS_PROJECT1_SOURCEBRANCHNAME] --> [master]...[RELEASE_ARTIFACTS_PROJECT2_SOURCEBRANCHNAME] --> [merge]...[RELEASE_ARTIFACTS_PROJECT3_SOURCEBRANCHNAME] --> [master]...[RELEASE_TRIGGERINGARTIFACT_ALIAS] --> [PROJECT2]...

This is also visible in a standard release view.

enter image description here

enter image description here

Ultimately we want to see if the triggering artifact's source branch name variable is set to merge, if so I short-circuit the release and skip all following tasks via Control Options Custom conditions. This is not an ideal situation as Pull Request builds still trigger unnecessary releases, however, it prevents any actual release action from occurring.

PowerShell task

Below is the PowerShell I'm currently using in the very first task

# Use the triggering artifact alias and constructing the name of the variable that will ultimately get us the source branch that triggered the release$SrcBranchName = "RELEASE_ARTIFACTS_$(('$(RELEASE.TRIGGERINGARTIFACT.ALIAS)' -replace '(^\s+|\s+$)','' -replace '\s+','_').ToUpper())_SOURCEBRANCHNAME"# Get the environment variable that holds the name of the source branch$SrcBranchName = Get-Item  env:$SrcBranchName | Select-Object -ExpandProperty ValueWrite-Host "SrcBranchName: $SrcBranchName"if ($SrcBranchName -eq "merge") {    Write-Host "Release caused by a PR - no further steps will run."}# Set an environment variable with the source branch name for use in a Custom Conditions ControlWrite-Host "##vso[task.setvariable variable=TriggeringArtifactSourceBranchName;]$SrcBranchName"

Custom Condition

Then for my custom conditions in each task, I use the following which skips the task if the TriggeringArtifactSourceBranchName is set to merge.

and(succeeded(), ne(variables['TriggeringArtifactSourceBranchName'], 'merge'))