Akom's Tech Ruminations

The way we use the Jenkins "Prepare an environment for the run" feature of the Environment Inject Plugin is this: we use the "Evaluated Groovy Script" to retrieve some info from a successful run of some other job (svn revisions, environment vars, whatever) in order to make it available to the environment of the current build. But what if that other job hasn't run successfully (yet)? I'd like to distinguish this "soft failure" from a real problem, so I'd like the build status to be "UNSTABLE". Here is how to do that in env inject:

currentBuild.@result = hudson.model.Result.UNSTABLE

However, that will not terminate the build. If you want to stop execution at this point, you'll have to put conditional logic in the job steps (but you can set a variable in EnvInject, and, for example, check it using Conditional Step)

Alternatively, to mark the build aborted and terminate immediately instead:

throw new InterruptedException()

Screenshot:

Continue reading "Marking Jenkins build UNSTABLE from environment inject groovy script"

Soon after Jenkins 1.609.1 support for JDK 1.6 was dropped altogether. This means that you can run jobs with whatever JDK you want as long as you are not using the Maven job type. Maven jobs require JDK 1.7 or higher (actually they run on whatever version the master is using, ignoring the JDK setting in the job configuration). This is a big deal for a shop that does extensive cross-platform testing. There are two solutions:

1. Convert hundreds (in our case) of Maven jobs to regular (freestyle) jobs. There appears to be no simple script to do this, so I wrote one here
2. Use maven toolchains to compile and test with a different JDK. Although converting jobs is a viable option that requires no additional setup, using toolchains may be preferred in some cases. For one thing, Jenkins offers the "Perform Release" button on maven jobs, something that is difficult to emulate in freestyle jobs.

Regarding option 1:

Initially I tried doing this using JobDSL, but that is way too time-consuming and hard to maintain. The simplest approach is to take the job XML, make minimal changes and push it back. Except that it's not that simple - you can't change the job type. You need to create new jobs, which is why I wrote a script to do all of the above. It will move the pre/post builders to the main builder list, and create a new maven job step in between. The rest is left unchanged and most of the XML is naturally valid for this version of jenkins/plugins since it's pulled from the live Jenkins.