Conditional Pull-Request building

This is a guest blog post from Andrew Phillips - long time member of the Apache jclouds project.

 

 

 

At Apache jclouds, we use DEV@cloud pretty extensively as part of our pull request review process (thanks again CloudBees!). 

 

 

 

 
We have jobs configured to trigger on pull requests to our repositories using the Validated Merge Plugin.

 

The Problem: Different Java versions on different branches

 

 
Our recent 1.8.0 release was the last jclouds release to support Java 6, and immediately after the release we moved our master branch to compile against Java 7 and started using some Java 7-only features.
 
This put our pull request builder jobs into a tricky position:
 
 
  • Pull requests against master will no longer compile with Java 6.
  • We still want to run a Java 6 job for any pull requests against older branches.
 
“Easy!” you might say: “Just set up your Java 6 job to trigger only on pull requests against non-master branches.” That’s what we thought, too. Only: it seems that there’s actually no way to do that using the Validated Merge plugin.
 

 

Run Condition and Conditional BuildStep plugins to the rescue!

 

 
Thanks to a tip from CloudBees’ Michael Neale, we had a look at the Conditional BuildStep Plugin (which depends on an extension point added by the Run Condition Plugin) to see what that would do.
 
The Conditional BuildStep Plugin allows you - surprise, surprise - to add one or multiple build steps which depend on a condition: if the condition is not met, you have a variety of choices about what to do with the build (fail, skip conditional steps but continue etc).
 
The plugin supports a variety of condition types, including time-based comparisons (“Don’t run on weekdays”) and value tests (“Does this environment variable or input parameter match this regex?”). 
 
We’re using the kitchen sink Execute Shell condition because we’re actually checking for a compilation target version of 1.6 in the POM, which is a more accurate check for us then simply determining which branch we’re currently on:
 
 
If you’re really looking to filter specifically on the branch the pull request has been open against, you could simply check the value of the $GIT_BRANCH environment variable in your condition. This value is automagically set by the Validated Merge Plugin to the correct value.
 

Wishful thinking!

 
This solution works well enough and does pretty much what we need, but it’s not perfect: you still need to install and configure the plugins, your job needs to be a free-style project, and ideally you wouldn’t want the build to be triggered at all if a pull request is opened against the “wrong” branch.
 
The Git Plugin already supports a number of advanced options such as ignoring commits to certain paths or by certain users, and it would be great if the Validated Merge plugin could add similar functionality at some point in the future.
 
— Andrew Phillips, Apache jclouds.
 
 

Add new comment