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!
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.
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.
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.
The ability to trigger releases based on the build's refspec isn't a capability at present.