3

We recently made a change to our build validation gate on PRs such that the builds expire "immediately" if another commit makes it into master branch before the current PR completes. See here.

Even though this change ensures that the master is always accurate/buildable/healthy, this seems to have few negative effects on developer productivity :

  1. team members have to continuously keep an eye on their PRs to requeue builds validations.
  2. Not only they have to requeue builds manually, but prior to doing that they have to manually rebase their branch before requeueing.
  3. as we move towards more smaller/shippable checkins in to master, the no. of times this occurring is expected to increase.

I want to automate (1) and (2). Is there a way I can setup VSTS build validation such that for all open PRs, upon build expiry, it automatically rebases/remerges the source branch with master and then requeues the build ?

dparkar
  • 1,934
  • 2
  • 22
  • 52
  • 1
    There is no way for VSTS itself to requeue and rebase automatically.You can find in the document (https://learn.microsoft.com/en-us/vsts/git/branch-policies?view=vsts#build-validation), for the immediately build expiration option, "This option is best for teams that have important branches with a lower volume of changes. Teams working in busy development branches may find it disruptive to wait for a build to complete every time the protected branch is updated". – Marina Liu Mar 26 '18 at 09:01
  • Besides, if `master` branch is for production versions, you can also change the git branching model (similar as this one http://nvie.com/posts/a-successful-git-branching-model/), such as all developers works on the `develop` branch. And then creating PR to merge `develop` branch into `master` branch with immediately experation is enough. – Marina Liu Mar 26 '18 at 09:05
  • Is there an existing User Voice request for this which I can up-vote ? Or can we create a new one ? – dparkar Mar 26 '18 at 21:26
  • There has no such user voice yet. You can create a new one here (https://visualstudio.uservoice.com/forums/330519-visual-studio-team-services). – Marina Liu Mar 27 '18 at 01:06

1 Answers1

1

I've run into this exact problem at my organization. Setting Build expiration to Immediately becomes too burdensome when there are multiple PRs all trying to get into the same time.

AFAIK - there's no way to automatically trigger a rebuild of all PRs targeting master whenever master is updated. I'm sure the basics are there if you want to hook into VSTS events and write the code yourself. But there's nothing out-of-box last time I looked.

What my organization did was to accept a compromise. We configure PRs so the build expires after 1 hour. This way there's no contention when multiple PRs are trying to be merged at the same time. However, this has the downside you describe in your original question VSTS : Invalidating builds on existing PRs when another commit makes it into master branch where it's possible for the target branch (ie master) to become broken because of a quick merger of two incompatible PRs.

We've ended up just embracing this limitation

  • We have a trigger on all of our branches (feature, master, etc) that whenever new commits are added, we automatically trigger a new build. This way if a PR managed to break master we get an email about it within a few minutes.

  • If the main branch (ie master) becomes broken, all new PRs will start failing builds. Thus, no new PRs can be merged in. This usually gets everyone's attention so the problem quickly bubbles up to the surface - and the whole team starts working to fix master.

  • Before we deploy master we run a full VSTS build, including unit tests. This way, if the main branch is broken (by two incompatible PRs or for any other reason) we make sure we halt the deployment.

So, unfortunately, we can't guarantee that master is always a 100% in a good state. Getting to 100% is just has too much negative impact on our workflow and productivity. So we embrace our limitations and make sure we are notified asap and can handle the situation when the branch breaks.

Philip Pittle
  • 11,821
  • 8
  • 59
  • 123
  • I think that's a fair compromise which I can try in our team. How did you setup (2) ? (all new PRs fail build if master build is broken) – dparkar Mar 23 '18 at 20:49
  • oh "new" PRs, so that should have latest from master and hence the build should fail. Okay. got it. – dparkar Mar 23 '18 at 20:51
  • Thanks ! Thats really helpful. Not marking this as answered just yet, hoping to get some input from VSTS folks. Will check back. – dparkar Mar 23 '18 at 20:52
  • 1
    @dparka - yup, "new" PRs would be prevented from merging because the build would fail as master would already be broken. Unless they (in)advenrtenly fixed whatever problems were already on master. And do wait for VSTS to chime in - if they have a better solution, I'd love to hear it! – Philip Pittle Mar 23 '18 at 21:23