13

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!

watdo
  • 667
  • 8
  • 22

4 Answers4

16

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://learn.microsoft.com/en-us/vsts/build-release/concepts/process/conditions

Jeff Shepler
  • 2,007
  • 2
  • 22
  • 22
  • 2
    This is the most elegant and correct answer in my opinion – Crwydryn Jun 15 '18 at 10:36
  • 1
    What about if you want to release an alpha version of a library whenever a PR gets merged to a develop branch? In this case you'd want those releases to occur *only* when the conditions in the branch policies have all been met (comment resolution, build, etc.) and the PR is ultimately completed, yes? – Crono Sep 24 '19 at 23:46
10

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.

enter image description here

2. Replace the cloned build for branch policy.

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

enter image description here

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.

Community
  • 1
  • 1
Marina Liu
  • 36,876
  • 5
  • 61
  • 74
  • 11
    This solutions will definitely work but it not as elegant as I would like. There are two problems here - First we create a build duplication, which is harder to maintain. And second, the gated build may have some steps which are not necessary at all to run again, such as lint and test (since they have just ran successfully on the same code a moment ago). But separating the artifact creation will also require running some of the build steps from the gated build again. My questions is - Can you offer a solution where there is no task duplication between the gated and the CI build? – kDar Sep 26 '17 at 07:20
  • And what if someone ran the CI build on the master branch without pull request? it will trigger the CD release pipeline as well !!? – Wahid Bitar Nov 15 '18 at 13:39
0

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'))

Anil
  • 131
  • 1
  • 2
0

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... enter image description here

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

IEnjoyEatingVegetables
  • 968
  • 3
  • 11
  • 30