VSTS release pull request build trigger

Question

My team are using the VSTS Build & Release mechanism, combined with pull request branch safety settings, so that code can only be merged in when a pull request is completed.

We are experiencing something odd though, in that when a pull-request is created (and a build is spawned to prove the commit) - the completion of this build triggered by the pull request also indirectly triggers a release because we have a release trigger setup.

This in itself is probably ok, but then what also happens is upon 'completing' the pull request, another build & release cycle takes place!

Is there a way of making VSTS release triggers only kick in when the pull request is completed and merged into the release branch?

Thank you!

Answer 1

We can specify a branch filter on the release trigger such that only builds of master will trigger a release. PR validation builds are done in a different branch. When approved and the branch is merged into master, that's the build you want triggering a release.

Annoyingly, they keep moving things around. At the time of this writing, when editing a release, under Pipeline, under Artifacts, on the artifact, there is a circle with a lightning bolt inside, tooltip says "Continuous deployment trigger" - click that. On the right, if the trigger is enabled, you'll see "Build branch filters". Click "+ Add" and select the master branch. Save the Release definition.

As for the build doing different things, we can now set conditions on tasks such that you can have a task only run on PR validation builds or only on master builds.

https://docs.microsoft.com/en-us/vsts/build-release/concepts/process/conditions

Answer 2

You just need to clone your current build definition and disable the CI build, and then use the cloned build to verify the created PR.

First, change for below settings as below:

1. Clone build.

Click ... button of the CI build -> Clone -> edit the cloned build definition -> disable CI build -> save.

2. Replace the cloned build for branch policy.

Open the branch policy -> edit the build validation policy -> select the cloned build definition instead -> save.

So the workflow will be:

1. The cloned build will to triggered when the pull request is created/changed.
2. When the cloned build queued successful, you can complete the PR.
3. When the PR is completed (changes has been merged), the CI build will be triggerd.
4. When the CI build queued successful, the CD release will be triggerd.

Now, only the PR is completed and merged into release branch, the release definition will be triggered.

Answer 3

Use Conditional statements for Build task to validate if the Build.Reason is "Pull Request".

Goto your Task > Expand "Control Options" > "Run this task" > Under this select "Custom Contions"

In Custom conditions specify below condition to filter out PullRequest Builds and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))

Answer 4

If you have the Enable Continuous Integration box checked(under the triggers tab) then it will queue another build after the PR completes. I haven't tried it but you could try adding another build def, with a manual trigger(via branch policies) but check the CI box for that one...

Image source: https://www.youtube.com/watch?v=uGAcWLnSU0A&t=582s