Can I use an Azure Dev Ops build definition both for a Release Management pipeline and a pull request but with the latter not triggering the pipeline

问题

In short; we want to use a build definition to both generate artifacts for Release Management and checking Pull Requests, but not allow the latter to trigger a new release.

We have CI build definition on our Git Repo feeding artifacts into a Release Management Pipeline. Like many teams we also have Pull Requests set up to protect our git master. We'd like to reuse our CI build to validate Pull Requests before they are merged in but doing so automatically triggers our release pipeline (bypassing the merge to master).

We've been working round this so far by duplicating builds but that feels clunky. Looking through the documentation there isn't an obvious way to filter a Release Trigger, or skip the publishing step in the build. I feel there must be away of preventing the trigger without duplicating the build but I can't see it!

回答1:

There is no out of box feature to achieve this for now, there is already a similar feature request submitted on VSTS User Voice and you can vote it: Trigger release definition only for specific branches.

The alternative way to achieve to this would updating your release definition to configure it to be triggered by "Manual", and then add a PowerShell script task in your build definition to check the source refs of current build and then trigger the release via VSTS Rest API.

回答2:

I'm not sure if this is too old a question for this answer to be valid, but if you're now using Azure DevOps (formerly VSTS) you can accomplish this by using the Control Options: Custom Conditions for the task of the CI build that publishes the artifacts.

---

回答3:

Azure Dev Ops now has a way of achieving this behaviour. You can modify the Continuous Deployment trigger for a Release definition. The two applicable options are:

• Disable the (handily titled) Pull Request trigger
• Add a branch filter i.e. include only master

Note another answer suggested making the artifact upload conditional, however we still needed the artifact for other reasons.

回答4:

The ability to trigger releases based on the build's refspec isn't a capability at present.

回答5:

In Azure DevOps I wasn't able to fully stop the releases from triggering but I was able to sort circuit them getting the branch that triggered the release and then using a custom condition on my release tasks, skip them if the triggering branch was merge

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 Value
Write-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 Control
Write-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'))

来源：https://stackoverflow.com/questions/39127892/can-i-use-an-azure-dev-ops-build-definition-both-for-a-release-management-pipeli