Recent Blog Posts

This blog post is the last one from the series of Google Summer of Code 2016, External Workspace Manager Plugin project. The previous posts are: Introductory blog post Alpha release announcement Beta release announcement In this post I would like to announce the 1.0.0 release of the External Workspace Manager Plugin version to the main update center. Here’s a highlight of the available features: Workspace share and reuse across multiple jobs, running on different nodes Automatic workspace cleanup Provide custom workspace path on the disk Disk Pool restrictions Flexible Disk allocation strategies All the above are detailed, with usage examples, on the plugin’s documentation page. Future work Currently, there is work in progress for the workspace browsing feature (see pull request #37). Afterwards, I’m planning to integrate fingerprints, so that the user can view a specific workspace in which other jobs was used. A particular feature that would be nice to have is to integrate the plugin with at least one disk provider (e.g. Amazon EBS, Google Cloud Storage). Many other features and improvements are still to come, they are grouped in the phase 3 EPIC: JENKINS-37543. The plugin’s repository is on GitHub. If you’d like to come up with new features or ideas, contributions are very welcome. Closing This was a Google Summer of Code 2016 project. A summary of the contributions that I’ve made to the Jenkins project during this time may be found here. It was a great experience, from which I learned a lot, and I’d wish I could repeat it every year. I’d like to thank to my mentors, Oleg Nenashev and Martin d’Anjou for all their support, good advices and help they gave me. Also, thanks to the Jenkins contributors with which I have interacted and helped me during this period. If you have any issues in setting up or using the plugin, please feel free to ask me on the plugin’s Gitter chat. Any feedback is welcome, and you may provide it either on the Gitter chat, or on Jira by using the external-workspace-manager-plugin component. Links Project repository Work product page GSoC page Jenkins GSoC Page

This blog post is a continuation of the External Workspace Manager Plugin related posts, starting with the introductory blog post, and followed by the alpha version release announcement. As the title suggests, the beta version of the External Workspace Manager Plugin was launched! This means that it’s available only in the Experimental Plugins Update Center. Take care when installing plugins from the Experimental Update Center, since they may change in backward-incompatible ways. It’s advisable not to use it for Jenkins production environments. The plugin’s repository is on GitHub. The complete plugin’s documentation can be accessed here. What’s new Bellow is a summary of the features added so far, since the alpha version. Multiple upstream run selection strategies It has support for the Run Selector Plugin (which is still in beta), so you can provide different run selection strategies when allocating a disk from the upstream job. Let’s suppose that we have an upstream job that clones the repository and builds the project: def extWorkspace = exwsAllocate 'diskpool1' node ('linux') { exws (extWorkspace) { checkout scm sh 'mvn clean install -DskipTests' } } In the downstream job, we run the tests on a different node, but we reuse the same workspace as the previous job: def run = selectRun 'upstream' def extWorkspace = exwsAllocate selectedRun: run node ('test') { exws (extWorkspace) { sh 'mvn test' } } The selectRun in this example selects the last stable build from the upstream job. But, we can be more explicit, and select a specific build number from the upstream job. def run = selectRun 'upstream', selector: [$class: 'SpecificRunSelector', buildNumber: UPSTREAM_BUILD_NUMBER] def extWorkspace = exwsAllocate selectedRun: run // ... When the selectedRun parameter is given to the exwsAllocate step, it will allocate the same workspace that was used by that run. The Run Selector Plugin has several run selection strategies that are briefly explained here. Automatic workspace cleanup Provides an automatic workspace cleanup by integrating the Workspace Cleanup Plugin. For example, if we need to delete the workspace only if the build has failed, we can do the following: def extWorkspace = exwsAllocate diskPoolId: 'diskpool1' node ('linux') { exws (extWorkspace) { try { checkout scm sh 'mvn clean install' } catch (e) { currentBuild.result = 'FAILURE' throw e } finally { step ([$class: 'WsCleanup', cleanWhenFailure: false]) } } } More workspace cleanup examples can be found at this link. Custom workspace path Allows the user to specify a custom workspace path to be used when allocating workspace on the disk. The plugin offers two alternatives for doing this: by defining a global workspace template for each Disk Pool This can be defined in the Jenkins global config, External Workspace Definitions section. by defining a custom workspace path in the Pipeline script We can use the Pipeline DSL to compute the workspace path. Then we pass this path as input parameter to the exwsAllocate step. def customPath = "${env.JOB_NAME}/${PULL_REQUEST_NUMBER}/${env.BUILD_NUMBER}" def extWorkspace = exwsAllocate diskPoolId: 'diskpool1', path: customPath // ... For more details see the afferent documentation page. Disk Pool restrictions The plugin comes with Disk Pool restriction strategies. It does this by using the restriction capabilities provided by the Job Restrictions Plugin. For example, we can restrict a Disk Pool to be allocated only if the Jenkins job in which it’s allocated was triggered by a specific user: Or, we can restrict the Disk Pool to be allocated only for those jobs whose name matches a well defined pattern: What’s next Currently there is ongoing work for providing flexible disk allocation strategies. The user will be able to define a default disk allocation strategy in the Jenkins global config. So for example, we want to select the disk with the most usable space as default allocation strategy: If needed, this allocation strategy may be overridden in the Pipeline code. Let’s suppose that for a specific job, we want to allocate the disk with the highest read speed. def extWorkspace = exwsAllocate diskPoolId: 'diskpool1', strategy: fastestRead() // ... When this feature is completed, the plugin will enter a final testing phase. If all goes to plan, a stable version should be released in about two weeks. If you have any issues in setting up or using the plugin, please feel free to ask me on the plugin’s Gitter chat. Any feedback is welcome, and you may provide it either on the Gitter chat, or on Jira by using the external-workspace-manager-plugin component. Links Project repository Project intro blog post Alpha version announcement GSoC page Jenkins GSoC Page

This is a guest post by Michael Neale, long time open source developer and contributor to the Blue Ocean project. If you are running parts of your pipeline on Linux, possibly the easiest way to get a clean reusable environment is to use: CloudBees Docker Pipeline plugin. In this short post I wanted to show how you can avoid installing stuff on the agents, and have per project, or even per branch, customized build environments. Your environment, as well as your pipeline is defined and versioned alongside your code. I wanted to use the Blue Ocean project as an example of a project that uses the CloudBees Docker Pipeline plugin. Environment and Pipeline for JavaScript components The Blue Ocean project has a few moving parts, one of which is called the "Jenkins Design Language". This is a grab bag of re-usable CSS, HTML, style rules, icons and JavaScript components (using React.js) that provide the look and feel for Blue Ocean. JavaScript and Web Development being what it is in 2016, many utilities are need to assemble a web app. This includes npm and all that it needs, less.js to convert Less to CSS, Babel to "transpile" versions of JavaScript to other types of JavaScript (don’t ask) and more. We could spend time installling nodejs/npm on the agents, but why not just use the official off the shelf docker image from Docker Hub? The only thing that has to be installed and run on the build agents is the Jenkins agent, and a docker daemon. A simple pipeline using this approach would be: node { stage "Prepare environment" checkout scm docker.image('node').inside { stage "Checkout and build deps" sh "npm install" stage "Test and validate" sh "npm install gulp-cli && ./node_modules/.bin/gulp" } } This uses the stock "official" Node.js image from the Docker Hub, but doesn’t let us customize much about the environment. Customising the environment, without installing bits on the agent Being the forward looking and lazy person that I am, I didn’t want to have to go and fish around for a Docker image every time a developer wanted something special installed. Instead, I put a Dockerfile in the root of the repo, alongside the Jenkinsfile : The contents of the Dockerfile can then define the exact environment needed to build the project. Sure enough, shortly after this, someone came along saying they wanted to use Flow from Facebook (A typechecker for JavaScript). This required an additional native component to work (via apt-get install). This was achieved via a pull request to both the Jenkinsfile and the Dockerfile at the same time. So now our environment is defined by a Dockerfile with the following contents: # Lets not just use any old version but pick one FROM node:5.11.1 # This is needed for flow, and the weirdos that built it in ocaml: RUN apt-get update && apt-get install -y libelf1 RUN useradd jenkins --shell /bin/bash --create-home USER jenkins The Jenkinsfile pipeline now has the following contents: node { stage "Prepare environment" checkout scm def environment = docker.build 'cloudbees-node' environment.inside { stage "Checkout and build deps" sh "npm install" stage "Validate types" sh "./node_modules/.bin/flow" stage "Test and validate" sh "npm install gulp-cli && ./node_modules/.bin/gulp" junit 'reports/**/*.xml' } stage "Cleanup" deleteDir() } Even hip JavaScript tools can emit that weird XML format that test reporters can use, e.g. the junit result archiver. The main change is that we have docker.build being called to produce the environment which is then used. Running docker build is essentially a "no-op" if the image has already been built on the agent before. What’s it like to drive? Well, using Blue Ocean, to build Blue Ocean, yields a pipeline that visually looks like this (a recent run I screen capped): This creates a pipeline that developers can tweak on a pull-request basis, along with any changes to the environment needed to support it, without having to install any packages on the agent. Why not use docker commands directly? You could of course just use shell commands to do things with Docker directly, however, Jenkins Pipeline keeps track of Docker images used in a Dockerfile via the "Docker Fingerprints" link (which is good, should that image need to change due to a security patch). Links The project used as as an example is here The pipeline is defined by the Jenkinsfile The environment is defined by the Dockerfile Read more on Docker Pipeline

This is a guest post by Liam Newman, Technical Evangelist at CloudBees. Rather than sitting and watching Jenkins for job status, I want Jenkins to send notifications when events occur. There are Jenkins plugins for Slack, HipChat, or even email among others. Note: Something is happening! I think we can all agree getting notified when events occur is preferable to having to constantly monitor them just in case. I’m going to continue from where I left off in my previous post with the hermann project. I added a Jenkins Pipeline with an HTML publisher for code coverage. This week, I’d like to make Jenkins to notify me when builds start and when they succeed or fail. Setup and Configuration First, I select targets for my notifications. For this blog post, I’ll use sample targets that I control. I’ve created Slack and HipChat organizations called "bitwiseman", each with one member - me. And for email I’m running a Ruby SMTP server called mailcatcher, that is perfect for local testing such as this. Aside for these concessions, configuration would be much the same in a non-demo situation. Next, I install and add server-wide configuration for the Slack, HipChat, and Email-ext plugins. Slack and HipChat use API tokens - both products have integration points on their side that generate tokens which I copy into my Jenkins configuration. Mailcatcher SMTP runs locally. I just point Jenkins at it. Here’s what the Jenkins configuration section for each of these looks like: Original Pipeline Now I can start adding notification steps. The same as last week, I’ll use the Jenkins Pipeline Snippet Generator to explore the step syntax for the notification plugins. Here’s the base pipeline before I start making changes: stage 'Build' node { // Checkout checkout scm // install required bundles sh 'bundle install' // build and run tests with coverage sh 'bundle exec rake build spec' // Archive the built artifacts archive (includes: 'pkg/*.gem') // publish html // snippet generator doesn't include "target:" // https://issues.jenkins.io/browse/JENKINS-29711. publishHTML (target: [ allowMissing: false, alwaysLinkToLastBuild: false, keepAll: true, reportDir: 'coverage', reportFiles: 'index.html', reportName: "RCov Report" ]) } This pipeline expects to be run from a Jenkinsfile in SCM. To copy and paste it directly into a Jenkins Pipeline job, replace the checkout scm step with git 'https://github.com/reiseburo/hermann.git'. Job Started Notification For the first change, I decide to add a "Job Started" notification. The snippet generator and then reformatting makes this straightforward: node { notifyStarted() /* ... existing build steps ... */ } def notifyStarted() { // send to Slack slackSend (color: '#FFFF00', message: "STARTED: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})") // send to HipChat hipchatSend (color: 'YELLOW', notify: true, message: "STARTED: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})" ) // send to email emailext ( subject: "STARTED: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]'", body: """ STARTED: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]': Check console output at " ${env.JOB_NAME} [${env.BUILD_NUMBER}]"""", recipientProviders: [[$class: 'DevelopersRecipientProvider']] ) } Since Pipeline is a Groovy-based DSL, I can use string interpolation and variables to add exactly the details I want in my notification messages. When I run this I get the following notifications: Job Successful Notification The next logical choice is to get notifications when a job succeeds. I’ll copy and paste based on the notifyStarted method for now and do some refactoring later. node { notifyStarted() /* ... existing build steps ... */ notifySuccessful() } def notifyStarted() { /* .. */ } def notifySuccessful() { slackSend (color: '#00FF00', message: "SUCCESSFUL: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})") hipchatSend (color: 'GREEN', notify: true, message: "SUCCESSFUL: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})" ) emailext ( subject: "SUCCESSFUL: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]'", body: """ SUCCESSFUL: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]': Check console output at " ${env.JOB_NAME} [${env.BUILD_NUMBER}]"""", recipientProviders: [[$class: 'DevelopersRecipientProvider']] ) } Again, I get notifications, as expected. This build is fast enough, some of them are even on the screen at the same time: Job Failed Notification Next I want to add failure notification. Here’s where we really start to see the power and expressiveness of Jenkins pipeline. A Pipeline is a Groovy script, so as we’d expect in any Groovy script, we can handle errors using try-catch blocks. node { try { notifyStarted() /* ... existing build steps ... */ notifySuccessful() } catch (e) { currentBuild.result = "FAILED" notifyFailed() throw e } } def notifyStarted() { /* .. */ } def notifySuccessful() { /* .. */ } def notifyFailed() { slackSend (color: '#FF0000', message: "FAILED: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})") hipchatSend (color: 'RED', notify: true, message: "FAILED: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})" ) emailext ( subject: "FAILED: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]'", body: """ FAILED: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]': Check console output at " ${env.JOB_NAME} [${env.BUILD_NUMBER}]"""", recipientProviders: [[$class: 'DevelopersRecipientProvider']] ) } Code Cleanup Lastly, now that I have it all working, I’ll do some refactoring. I’ll unify all the notifications in one method and move the final success/failure notification into a finally block. stage 'Build' node { try { notifyBuild('STARTED') /* ... existing build steps ... */ } catch (e) { // If there was an exception thrown, the build failed currentBuild.result = "FAILED" throw e } finally { // Success or failure, always send notifications notifyBuild(currentBuild.result) } } def notifyBuild(String buildStatus = 'STARTED') { // build status of null means successful buildStatus = buildStatus ?: 'SUCCESS' // Default values def colorName = 'RED' def colorCode = '#FF0000' def subject = "${buildStatus}: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]'" def summary = "${subject} (${env.BUILD_URL})" def details = """ STARTED: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]': Check console output at " ${env.JOB_NAME} [${env.BUILD_NUMBER}]"""" // Override default values based on build status if (buildStatus == 'STARTED') { color = 'YELLOW' colorCode = '#FFFF00' } else if (buildStatus == 'SUCCESS') { color = 'GREEN' colorCode = '#00FF00' } else { color = 'RED' colorCode = '#FF0000' } // Send notifications slackSend (color: colorCode, message: summary) hipchatSend (color: color, notify: true, message: summary) emailext ( subject: subject, body: details, recipientProviders: [[$class: 'DevelopersRecipientProvider']] ) } You have been notified! I now get notified twice per build on three different channels. I’m not sure I need to get notified this much for such a short build. However, for a longer or complex CD pipeline, I might want exactly that. If needed, I could even improve this to handle other status strings and call it as needed throughout my pipeline. Links Slack Plugin HipChat Plugin Email-ext Plugin Jenkins Pipeline Snippet Generator

This is a guest post by Liam Newman, Technical Evangelist at CloudBees. Most projects need more that just JUnit result reporting. Rather than writing a custom plugin for each type of report, we can use the HTML Publisher Plugin. Let’s Make This Quick I’ve found a Ruby project, hermann, I’d like to build using Jenkins Pipeline. I’d also like to have the code coverage results published with each build job. I could write a plugin to publish this data, but I’m in a bit of hurry and the build already creates an HTML report file using SimpleCov when the unit tests run. Simple Build I’m going to use the HTML Publisher Plugin to add the HTML-formatted code coverage report to my builds. Here’s a simple pipeline for building the hermann project. stage 'Build' node { // Checkout checkout scm // install required bundles sh 'bundle install' // build and run tests with coverage sh 'bundle exec rake build spec' // Archive the built artifacts archive (includes: 'pkg/*.gem') } This pipeline expects to be run from a Jenkinsfile in SCM. To copy and paste it directly into a Jenkins Pipeline job, replace the checkout scm step with git 'https://github.com/reiseburo/hermann.git'. Simple enough, it builds, runs tests, and archives the package. Now I just need to add the step to publish the code coverage report. I know that rake spec creates an index.html file in the coverage directory. I’ve already installed the HTML Publisher Plugin. How do I add the HTML publishing step to the pipeline? The plugin page doesn’t say anything about it. Snippet Generator to the Rescue Documentation is hard to maintain and easy to miss, even more so in a system like Jenkins with hundreds of plugins the each potential have one or more groovy fixtures to add to the Pipeline. The Pipeline Syntax"Snippet Generator" helps users navigate this jungle by providing a way to generate a code snippet for any step using provided inputs. It offers a dynamically generated list of steps, based on the installed plugins. From that list I select the publishHTML step: Then it shows me a UI similar to the one used in job configuration. I fill in the fields, click "generate", and it shows me snippet of groovy generated from that input. HTML Published I can use that snippet directly or as a template for further customization. In this case, I’ll just reformat and copy it in at the end of my pipeline. (I ran into a minor bug in the snippet generated for this plugin step. Typing error string in my search bar immediately found the bug and a workaround.) /* ...unchanged... */ // Archive the built artifacts archive (includes: 'pkg/*.gem') // publish html // snippet generator doesn't include "target:" // https://issues.jenkins.io/browse/JENKINS-29711. publishHTML (target: [ allowMissing: false, alwaysLinkToLastBuild: false, keepAll: true, reportDir: 'coverage', reportFiles: 'index.html', reportName: "RCov Report" ]) } When I run this new pipeline I am rewarded with an RCov Report link on left side, which I can follow to show the HTML report. I even added the keepAll setting to let I can also go back an look at reports on old jobs as more come in. As I said to to begin with, this is not as slick as what I could do with a custom plugin, but it is much easier and works with any static HTML. Links HTML Publisher Plugin Jenkins Pipeline Snippet Generator

Currently it’s quite difficult to share and reuse the same workspace between multiple jobs and across nodes. There are some possible workarounds for achieving this, but each of them has its own drawback, e.g. stash/unstash pre-made artifacts, Copy Artifacts plugin or advanced job settings. A viable solution for this problem is the External Workspace Manager plugin, which facilitates workspace share and reuse across multiple Jenkins jobs and nodes. It also eliminates the need to copy, archive or move files. You can learn more about the design and goals of the External Workspace Manager project in this introductory blog post. I’d like to announce that an alpha version of the External Manager Plugin has been released! It’s now public available for testing. To be able to install this plugin, you must follow the steps from the Experimental Plugins Update Center blog post. Please be aware that it’s not recommended to use the Experimental Update Center in production installations of Jenkins, since it may break it. The plugin’s wiki page may be accessed here. The documentation that helps you get started with this plugin may be found on the README page. To get an idea of what this plugin does, which are the features implemented so far and to see a working demo of it, you can watch my mid-term presentation that is available here. The slides for the presentation are shared on Google Slides. My mentors, Martin and Oleg, and I have set up public meetings related to this plugin. You are invited to join our discussions if you’d like to get more insight about the project. The meetings are taking place twice a week on the Jenkins hangout, every Monday at 12 PM UTC and every Thursday at 5 PM UTC. If you have any issues in setting up or using the plugin, please feel free to ask me on the plugin’s Gitter chat. The plugin is open-source, having the repository on GitHub, and you may contribute to it. Any feedback is welcome, and you may provide it either on the Gitter chat, or on Jira by using the external-workspace-manager-plugin component. Links Project repository Plugin wiki page Mid-term presentation Project intro blog post GSoC page Jenkins GSoC Page

This is a guest post by Liam Newman, Technical Evangelist at CloudBees. In this blog post, I’ll show you how to speed up your pipeline by using the Parallel Test Executor Plugin. So much to do, so little time…​ In my career, I’ve helped many teams move to continuous integration and delivery. One problem we always encounter is how to run all the tests needed to ensure high-quality changes while still keeping pipeline times reasonable and changes flowing smoothly. More tests mean greater confidence, but also longer wait times. Build systems may or may not support running tests in parallel, but they still only use one machine even while other lab machines sit idle. In these cases, parallelizing test execution across multiple machines is a great way to speed up pipelines. The Parallel Test Executor plugin lets us leverage Jenkins do just that with no disruption to the rest of the build system. Serial Test Execution For this post, I’ll be running a pipeline based on the Jenkins Git Plugin. I’ve modified the Jenkinsfile from that project to allow us to compare execution times to our later changes, and I’ve truncated the "mvn" utility method since it remains unchanged. You can find the original file here. node { stage 'Checkout' checkout scm stage 'Build' /* Call the Maven build without tests. */ mvn "clean install -DskipTests" stage 'Test' runTests() /* Save Results. */ stage 'Results' /* Archive the build artifacts */ archive includes: 'target/*.hpi,target/*.jpi' } void runTests(def args) { /* Call the Maven build with tests. */ mvn "install -Dmaven.test.failure.ignore=true" /* Archive the test results */ junit '**/target/surefire-reports/TEST-*.xml' } /* Run Maven */ void mvn(def args) { /* ... */ } This pipeline expects to be run from a Jenkinsfile in SCM. To copy and paste it directly into a Jenkins Pipeline job, replace the checkout scm step with git 'https://github.com/jenkinsci/git-plugin.git'. This is a Maven project, so the Jenkinsfile is pretty simple. I’ve split the Maven build into separate “Build” and “Test” stages. Maven doesn’t support this split very well, it wants to run all the steps of the lifecycle in order every time. So, I have to call Maven twice: first using the “skipTests” property to do only build steps in the first call, and then a second time with out that property to run tests. On my quad-core machine, executing this pipeline takes about 13 minutes and 30 seconds. Of that time, it takes 13 minutes to run about 2.7 thousand tests in serial. Parallel Test Execution This looks like an ideal project for parallel test execution: a short build followed by a large number of serially executed tests that consume the most of the pipeline time. There are a number of things I could try to speed this up. For example, I could modify test harness to look for ways to parallelize the test execution on this single machine. Or I could try speed up the tests themselves. Both of those can be time-consuming and both risk destabilizing the tests. I’d need to know more about the project to do it well. I’ll avoid that risk by using Jenkins and the Parallel Test Executor Plugin to parallelize the tests across multiple nodes instead. This will isolate the tests from each other, while still giving us speed gains from parallel execution. The plugin reads the list of tests from the results archived in the previous execution of this job and splits that list into a specified number of sublists. I can then use those sublists to execute the tests in parallel, passing a different sublist to each node. Let’s look at how this changes the pipeline: node { /* ...unchanged... */ } void runTests(def args) { /* Request the test groupings. Based on previous test results. */ /* see https://wiki.jenkins.io/display/JENKINS/Parallel+Test+Executor+Plugin and demo on github /* Using arbitrary parallelism of 4 and "generateInclusions" feature added in v1.8. */ def splits = splitTests parallelism: [$class: 'CountDrivenParallelism', size: 4], generateInclusions: true /* Create dictionary to hold set of parallel test executions. */ def testGroups = [:] for (int i = 0; i }. */ /* includes = whether list specifies tests to include (true) or tests to exclude (false). */ /* list = list of tests for inclusion or exclusion. */ /* The list of inclusions is constructed based on results gathered from */ /* the previous successfully completed job. One additional record will exclude */ /* all known tests to run any tests not seen during the previous run. */ testGroups["split-${i}"] = { // example, "split3" node { checkout scm /* Clean each test node to start. */ mvn 'clean' def mavenInstall = 'install -DMaven.test.failure.ignore=true' /* Write includesFile or excludesFile for tests. Split record provided by splitTests. */ /* Tell Maven to read the appropriate file. */ if (split.includes) { writeFile file: "target/parallel-test-includes-${i}.txt", text: split.list.join("\n") mavenInstall += " -Dsurefire.includesFile=target/parallel-test-includes-${i}.txt" } else { writeFile file: "target/parallel-test-excludes-${i}.txt", text: split.list.join("\n") mavenInstall += " -Dsurefire.excludesFile=target/parallel-test-excludes-${i}.txt" } /* Call the Maven build with tests. */ mvn mavenInstall /* Archive the test results */ junit '**/target/surefire-reports/TEST-*.xml' } } } parallel testGroups } /* Run Maven */ void mvn(def args) { /* ... */ } That’s it! The change is significant but it is all encapsulated in this one method in the Jenkinsfile. Great (ish) Success! Here’s the results for the new pipeline with parallel test execution: The tests ran almost twice as fast, without changes outside pipeline. Great! However, I used 4 test executors, so why am I not seeing a 4x? improvement. A quick review of the logs shows the problem: A small number of tests are taking up to 5 minutes each to complete! This is actually good news. It means that I should be able to see further improvement in pipeline throughput just by refactoring those few long running tests into smaller parts. Conclusion While I would like to have seen closer to a 4x improvement to match to number of executors, 2x is still perfectly respectable. If I were working on a group of projects with similar pipelines, I’d be completely comfortable reusing these same changes on my other project and I’d expect to similar improvement without any disruption to other tools or processes. Links https://wiki.jenkins.io/display/JENKINS/Parallel+Test+Executor+Plugin

This is a guest post by Aleksei Besogonov, Senior Software Developer at Amazon Web Services. Earlier this year, we published a case study on how Lyft has used Amazon EC2 Spot instances to save 75% on their continuous delivery infrastructure costs by simply changing four lines of code. Several other EC2 customers like Mozilla have also reduced costs of their continuous integration, deployment and testing pipelines by up to 90% on Spot instances. You can view the current savings on Spot instances over EC2 On-demand instances using the Spot Bid Advisor : AWS Spot instances are spare EC2 instances that you can bid on. While your Spot instances may be terminated when EC2’s spare capacity declines, you can automatically replenish these instances and maintain your target capacity using EC2 Spot fleets. As each instance type and Availability Zone provides an alternative capacity pool, you can select multiple such pools to launch the lowest priced instances currently available by launching a Spot fleet on the Amazon EC2 Spot Requests console or using the AWS CLI/SDK tools. In this walkthrough, we’ll show you how to configure Jenkins to automatically scale a fleet of Spot instances up or down depending on the number jobs to be completed. Request an Amazon EC2 Spot fleet To get started, login to Amazon EC2 console, and click on Spot Requests in the left hand navigation pane. Alternatively, you can directly login to Amazon EC2 Spot Requests console. Then click on the Request Spot Instances button at the top of the dashboard. In the Spot instance launch wizard, select the Request & Maintain option to request a Spot fleet that automatically provisions the most cost-effective EC2 Spot instances, and replenishes them if interrupted. Enter an initial target capacity, choose an AMI, and select multiple instance types to automatically provision the lowest priced instances available. On the next page, ensure that you have selected a key pair, complete the launch wizard, and note the Spot fleet request ID. Amazon EC2 Spot fleet automates finding the lowest priced instances for you, and enables your Jenkins cluster to maintain the required capacity; so, you don’t need any bidding algorithms to provision the optimal Spot instances over time. Configure Jenkins Install the Plugin From the Jenkins dashboard, select Manage Jenkins, and then click Manage Plugins. On the Available tab, search for and select the EC2 Fleet Jenkins Plugin. Then click the Install button. After the plugin installation is completed, select Manage Jenkins from the Jenkins dashboard, and click Configure System. In the Cloud section, select Amazon Spot Fleet to add a new Cloud. Configure AWS Credentials Next, we will configure the AWS and agent node credentials. Click the Add button next to AWS Credentials, select Jenkins, and enter your AWS Access Key, secret, and ID. Next, click the Add button in the Spot fleet launcher to configure your agents with an SSH key. Select Jenkins, and enter the username and private key (from the key pair you configured in your Spot fleet request) as shown below. Confirm that the AWS and SSH credentials you just added are selected. Then choose the region, and the Spot fleet request ID from the drop-down. You can also enter the maximum idle time before your cluster automatically scales down, and the maximum cluster size that it can scale up to. Submit Jobs and View Status After you have finished the previous step, you can view the EC2 Fleet Status in the left hand navigation pane on the Jenkins dashboard. Now, as you submit more jobs, Jenkins will automatically scale your Spot fleet to add more nodes. You can view these new nodes executing jobs under the Build Executor Status. After the jobs are done, if the nodes remain free for the specified idle time (configured in the previous step), then Jenkins releases the nodes, automatically scaling down your Spot fleet nodes. Build faster and cheaper If you have a story to share about your team or product, or have a question to ask, do leave a comment for us; we’d love to connect with you!