I am Minudika Malshan, an undergraduate student in Computer Science and Engineering from University of Moratuwa, Sri Lanka.

As a person who is passionate in open source software development and seeking for new knowledge and experience, I am willing to give my contribution for this project.

LinkedIn | Twitter

The Support-Core Plugin provides the basic infrastructure for generating "bundles" of support information with Jenkins. There are two kinds of bundles.

However current support-core plugin is not much user friendly. The object of this project is to make it more user friendly by adding some features which make a sophisticated environment for the user who use support plugin.

In this project scope, there are three features and improvements we are going to consider.

Arnaud Héritier and Steven Christou are guiding me through the project as my mentors.

Additionally, Jenkins World offers great opportunities for hands-on learning, exploring and networking:

Due to its popularity in previous years, we are bringing back the plugin development workshop. This workshop will introduce developers to the Jenkins plugin ecosystem and terminology. The goal is to provide a cursory overview of the resources available to Jenkins plugin developers. Armed with this information, Jenkins developers can learn how to navigate the project and codebase to find answers to their questions.

BoFs, as they are usually known, will be a new addition to Jenkins World this year. Sessions will be curated on various technical topics from DevOps to how enterprises are integrating Jenkins in their environment. Discussions will be lead by the industry’s brightest minds who have an influence in shaping the future of Jenkins.

Got a Jenkins question that’s been keeping you up at night? Need to bounce ideas off somebody? Or you just need someone to fix your Jenkins issue? This is your chance to get connected with the Jenkins Experts. Experts will be on hand to help with all your Jenkins needs on Sept 14th & 15th.

The objective of this session is to help you assess your level of readiness for the certification exam - either the Certified Jenkins Engineer (CJE/open source) certification or the Certified CloudBees Jenkins Platform Engineer (CCJPE/CloudBees-specific) certification. After an overview about the certification program, a Jenkins expert from CloudBees will walk you through the various sections of the exam, highlighting the important things to master ahead of time, not only from a pure knowledge perspective but also in terms of practical experience. This will be an interactive session.

Don’t miss out on Super Early Bird Rate $399. Price goes up after July 1.

At the beginning of the journey there were several projects using roughly the same technologies. Those projects had several branches, for maintenance of releases, for new features.

In turn, each of those branches had to be carefully built, deployed on different platforms and versions, promoted so they could be tested for functionalities, performances and security, and then promoted again for actual delivery.

Additionally, we had to offer the test teams the means to deploy any version of their choice on any supported platform in order to carry out some manual tests.

This represented, for each branch, around 20 jobs. Multiply this by the number of branches and projects, and there you are: more than two years after the start of the story, we had more than 3500 jobs.

3500 jobs. Half a dozen people to manage them all…​

How did we deal with this load?

We were lucky enough to have several assets:

We also knew that, in order to scale, we’d have to provide a solution with the following characteristics:

Creating pipelines using the Job DSL and embedding the scripts in the code was simple enough. But what about branching? We needed a mechanism to allow the creation of pipelines per branch, by downloading the associated DSL and to run it in a dedicated folder.

But then, all those projects, all those branches, they were mostly using the same pipelines, give or take a few configurable items. Going this way would have lead to a terrible duplication of code, transforming a job maintenance nightmare into a code maintenance nightmare.

Our trick was to transform this vision of "pipeline as code" into a "pipeline as configuration":

Once this was done, the only remaining trick was to automate the creation, update, start and deletion of the pipelines using SCM events. By enabling SCM hooks (in GitHub, BitBucket or even in Subversion), we could:

Once a project wants to go in our ecosystem, the Jenkins team "seeds" the project into Jenkins, by running a job and giving a few parameters.

It will create a folder for the project and grant proper authorisations, using Active Directory group names based on the project name.

The hook for the project must be registered into the SCM and you’re up and running.

Mixing the use of strong pipeline libraries configured by properties and the direct use of the Jenkins Job DSL is still possible. The Seed plugin supports all kinds of combinations:

Usually, we tried to have a maximum reuse, through only pipeline libraries, for most of our projects, but in other circumstances, we were less strict and allowed some teams to develop their own pipeline script.

In the end, what did we achieve?

Self service✔︎

Security✔︎

Simplicity✔︎

Extensibility✔︎

Now, what about the Pipeline plugin? Both this plugin and the Seed plugin have common functionalities:

What we have found in our journey is that having a "pipeline as configuration" was the easiest and most secure way to get a lot of projects on board, with developers not knowing Jenkins and even less the DSL.

The outcome of the two plugins is different:

If time allows, it would be probably a good idea to find a way to integrate the functionalities of the Seed plugin into the pipeline framework, and to keep what makes the strength of the Seed plugin:

You can find additional information about the Seed plugin and its usage at the following links:

Every time I’ve moved a team 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 only on 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.

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.

It’s a Maven project, so the Jenkinsfile is pretty simple. As noted above, I’ve split the Maven build into separate “Build” and “Test” stages. Maven doesn’t support this split very well, it wants to run its 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.

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 optimize this. 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 destablizing 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 will read the list of tests from the results archived in the previous execution of this job and splits that list into the 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:

That’s it! The change is significant but it is all encapsulated in this one method in the Jenkinsfile.

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 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.

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.

Meeting link

Both meetings will be conducted and recorded via Hangouts on Air. The recorded sessions will be made public after the meetup. The agenda may change a bit.

Tool Auto-Installers are exposed in Pipeline through the tool step and onci.jenkins.io we already had JDK8 and Groovy available. This meant that the Jenkinsfile would invoke tool and Pipeline would automatically install the desired tool on the agent executing the current Pipeline steps.

The tool step does not modify the PATH environment variable, so it’s usually used in conjunction with the withEnv step, for example:

Satisfying the MongoDB dependency would still be tricky. If I caved in and installed MongoDB on a single unicorn agent in the cluster, what could I say the next time somebody asked for a special, one-off, piece of software installed on our Jenkins build agents?

After doing my usual complaining and whining, I discovered that the CloudBees Docker Pipeline plugin provides the ability to run containers inside of aJenkinsfile. To make things even better, there areofficial MongoDB docker images readily available on DockerHub!

This feature requires that the machine has a running Docker daemon which is accessible to the user running the Jenkins agent. After that, running a container in the background is easy, for example:

The beauty, to me, of this example is that you can pass aclosure to withRun which will execute while the container is running. When the closure is finished executin, just the sh step in this case, the container is destroyed.

With that system requirement satisfied, the rest of the stages of the Pipeline fell into place. We now have a single source of truth, theJenkinsfile, for the sequence of dependent tasks which need to be executed, accounting for variations in systems requirements, and it actually generatesthose pretty blue charts!

Of course, a nice added bonus is the beautiful visualization of ournew Pipeline!

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.

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.

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.

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 "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.

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

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.

I thing 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 thehermann 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.

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 theSlack,HipChat, and Email-ext plugins. Slack and HipChat use API tokens - both products have integration points on their side that make 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:

Now I can start adding notification steps. The same aslast 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:

For the first change, I decide to add a "Job Started" notification. The snippet generator and then reformatting makes this straightforward:

Since Pipeline is a Groovy-based DSL, I can usestring interpolation and variables to add exactly the details I want in my notification messages. When I run this I get the following notifications:

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.

Again, I get notifications, as expected. This build is fast enough, some of them are even on the screen at the same time:

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.

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.

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.

Building uponTom's great work onServer Sent Events (SSE) bothCliff andTom worked on making the all the screens in Blue Ocean update without manual refreshes.

SSE is a great technology choice for new web apps as it only pushes out events to the client when things have changed on the server. That means there’s a lot less traffic going between your browser and the Jenkins server when compared to the continuous AJAX polling method that has been typical of Jenkins in the past.

Keith has been working with Vivek to drive out a new set of extension points that allow us to build a new rest reporting UI in Blue Ocean. Today this works for JUnit test reports but can be easily extended to work with other kinds of reports.

Thorsten andJosh have been hard at work breaking down the log into steps and making the live log tailing follow the pipeline execution - which we’ve lovingly nicknamed the “karaoke mode”

Tom has been on allowing users to trigger jobs from Blue Ocean, which is one less reason to go back to the Classic UI :)

Many of you have asked us questions about how you can try Blue Ocean today and have resorted to building the plugin yourself or running our Docker image.

We wanted to make the process of trying Blue Ocean in its unfinished state by publishing the plugin to the experimental update center - it’s available today!

So what is the Experimental Update Center? It is a mechanism for the Jenkins developer community to share early previews of new plugins with the broader user community. Plugins in this update center are experimental and we strongly advise not running them on production or Jenkins systems that you rely on for your work.

That means any plugin in this update center could eat your Jenkins data, cause slowdowns, degrade security or have their behavior change at no notice.

You can learn how toactivate the experimental update center on this post.

Stay tuned for more updates!

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:

This uses the stock "official" Node.js image from the Docker Hub, but doesn’t let us customize much about the environment.

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 apull 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:

The Jenkinsfile pipeline now has the following contents:

The main change is that we have docker.build being called to produce theenvironment which is then used. Running docker build is essentially a "no-op" if the image has already been built on the agent before.

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.

Bellow is a summary of the features added so far, since the alpha version.

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.

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 onJira by using the external-workspace-manager-plugin component.

For most Rails applications there are few, if any, changes needed to enable continuous delivery with Jenkins. In the case ofcfp-app, I added two gems to get the most optimal integration into Jenkins:

Adding these was simple, I just needed to update the Gemfile and theRakefile in the root of the repository to contain:

With the cfp-app project set up, next on the list is to ensure that Jenkins itself is ready. Generally I suggest running the latest LTS of Jenkins; for this demonstration I used Jenkins 2.7.1 with the following plugins:

I also used theGitHub Organization Folder plugin to automatically create pipeline items in my Jenkins instance; that isn’t required for the demo, but it’s pretty cool to see repositories and branches with a Jenkinsfile automatically show up in Jenkins, so I recommend it!

In addition to the plugins listed above, I also needed at least one Jenkins agent with the Docker daemon installed and running on it. I label these agents with "docker" to make it easier to assign Docker-based workloads to them in the future.

Any Linux-based machine with Docker installed will work, in my case I was provisioning on-demand agents with theAzure plugin which, like theEC2 plugin, helps keep my test costs down.

To make sense of the various things that the Jenkinsfile needs to do, I find it easier to start by simply defining the stages of my pipeline. This helps me think of, in broad terms, what order of operations my pipeline should have. For example:

As mentioned previously, this Jenkinsfile is going to rely heavily on theCloudBees Docker Pipeline plugin. The plugin provides two very important features:

Like most Rails applications, one can effectively test the application with two commands: bundle install followed by bundle exec rake. I already had some Docker images prepared with RVM and Ruby 2.3.0 installed, which ensures a common and consistent starting point:

Unfortunately, with this application, the bundle exec rake command will fail if PostgreSQL isn’t available when the process starts. This is where the second important feature of the CloudBees Docker Pipeline plugin comes into effect: the ability to run a container in the "background."

Using Brakeman, the security scanner for Ruby on Rails, is almost trivially easy inside of Jenkins Pipeline, thanks to theBrakeman plugin which implements the publishBrakeman step.

Building off our example above, we can implement the "Security scan" stage:

Once the tests and security scanning are all working properly, we can start to set up the deployment stage. Jenkins Pipeline provides the variablecurrentBuild which we can use to determine whether our pipeline has been successful thus far or not. This allows us to add the logic to only deploy when everything is passing, as we would expect:

I have gratuitously commented the fullJenkinsfile which I hope is a useful summation of the work outlined above. Having worked on a number of Rails applications in the past, the consistency provided by Docker and Jenkins Pipeline above would have definitely improved those projects' delivery times. There is still room for improvement however, which is left as an exercise for the reader. Such as: preparing new containers with all theirdependencies built-in instead of installing them at run-time. Or utilizing the parallel step for executing RSpec across multiple Jenkins agents simultaneously.

The beautiful thing about defining your continuous delivery, and continuous security, pipeline in code is that you can continue to iterate on it!

Pull requests on our platform are evaluated from several angles: static code analysis including linting and security audits, javascript unit tests, python unit tests, acceptance tests and accessibility tests. Using an elixir of plugins, including the GitHub Pull Request Builder Plugin, we put more direct feedback into the hands of the contributor so s/he can quickly decide how much digging is going to be needed.

For example, if I made adjustments to my branch and know more requirements are coming, then I may not be as worried about passing the linter; however, if my unit tests have failed, I likely have a problem I need to address regardless of when the new requirements arrive. Timing is important as well. Splitting out the contexts means we can run tests in parallel and report results faster.

Occasionally the feedback mechanism fails. It is oftentimes a flaky condition in a test or in test setup. (Solving flakiness is a different discussion I’m sidestepping. Accept the fact that the system fails for purposes of this blog entry.) Engineers are armed with the power of re-running specific contexts, also available through the PR plugin. A developer can say “jenkins run bokchoy” to re-run the acceptance tests, for example. A developer can also re-run everything with “jenkins run all”. These phrases are set through the GitHub Pull Request Builder configuration.

Splitting the contexts has also given us important data points for our Tools team to help in highlighting things like flaky tests, time to feedback and other metrics that help the org prioritize what’s important. We use this with a log aggregator (in our case, Splunk) to produce valuable reports such as this one.

I could go on! The short answer here is we have an intuitive way of divvying up our tests, not only for optimizing the overall amount of time it takes to get build results, but also to make the experience more user-friendly to developers.

I’ll be presenting more of this concept and expanding on the edX configuration details at Jenkins World in September.