Jenkins Blogs

Syndicate content
Pipes Output
Updated: 17 min 31 sec ago

Upcoming in office horus: Jenkins 2.0

Thu, 2015-10-01 12:51

I hope many of you have had a chance to see the Jenkins 2.0 thread. I'm going to use the office hours next Wednesday to go through this proposal.

This is still primarily for developers in the project, as it's "just" a proposal with lots of details unspecified. It's more meant to help people understand where I'm coming from and what goals I have in mind for this effort.

As always, this will be on Hangout on air. The event page is here, and if you want to participate in the discussion, join here. Read-only viewers should use YouTube to watch, and you can still send questions in real time to IRC and I'll make sure to go through them.

Bay Area JAM

Wed, 2015-09-30 10:18

Last week, the first Jenkins Area Meetup (JAM) took place in San Jose, CA on Wednesday, Sept 23. What a way to kick off the first JAM other than to have Docker, John Willis as our guest speaker. John talked about immutable infrastructure and its benefits and role of containers.

Kohsuke discussed Jenkins Workflow, the motivation behind the same and latest features of Jenkins Workflow like multi branch support followed by docker use cases. The highlight of the meetup was definitely Kohsuke breaking the news about Jenkins 2.0 and his vision and motivation behind it.

The next Bay Area JAM is slated for Oct 21. Be sure to check HERE for the agenda. We’d love to have you join us if you’re in the area. If you’re interested in speaking, or become a food & bev, venue, or recording sponsor please send email to the organizer or

GUI improvements on the horizon

Tue, 2015-09-29 19:12

This past Thursday, September 24th, 2015, I presented a couple of prototypes of what I hope will be the future of the Jenkins GUI. Or perhaps more correctly, close enough to the future to start generating positive feedback from you the community that improving the Jenkins GUI is important and some pieces that I am showing are going in the right direction. If you have ~45 minutes to spare, I recommend the video (the narrator's voice is very soothing). If not, I offer the following as a reasonable summary.

Jenkins has a lot of strengths as tool. Its robust user community along with its thoughtful and extensible design are two of the most immediate. They are the two pillars that have made Jenkins the leader in the CD/CI space and the de facto choice for most of us looking to automate our build and test processes. But let's face it, by today's standards, the GUI doesn't really sing. I will even go so far as to say, I believe it is a platform liability at the moment, and even among we the Jenkins faithful, few of us look forward to using it.

In an effort to turn that tide, I traveled to this year's 3 main JUC events, in DC, London, and Santa Clara, pushing the idea that enhancement is possible and providing an evolving sketch of what that might look like. The three main areas of enhancement I have targeted for a first round of improvement are these:

Soon to follow, but not yet prototyped by me would be pieces dedicated to monitoring jobs in Jenkins as well as node and resource utilization and efficiency. Rightly or wrongly, I have started with the create and configure side of the GUI, as I see it as somewhat primary in a typical job creation scenario (you have to create a job before you can monitor it), but this second piece is no less important. Sadly, lips service is all I can offer you today, but more prototypes and video demonstrations are on the way.

Item Creation and Configuration in Jenkins

In most use cases, item creation means creating a freestyle job, so that is what I use as my base use case example. It is important to note, however, that most configuration in Jenkins happens through a shared set of GUI components. These components are a blend of Jelly files and Javascript and can be found in the .../main/resources/lib/form directory in the Jenkins source code. In operating on these pieces, I have the opportunity to effectively enhance broad areas of the Jenkins experience, including aspects of plugin use that share these components. This greatly increases the upside of the effort as well as the possible drama and side effects, which I will go into more detail on later.

As for the upside piece, the first bit of improvement I am looking to attain is breaking up the many 'toilet paper' style unbroken configuration lists sprinkled throughout Jenkins. The first example of this appears in item creation. On first installation, this issue is not immediately obvious, but if you have installed a variety of plugins or chosen to purchase CloudBee's Jenkins Enterprise product, you will find that Jenkins can have quite a few types of items to create. While they do have descriptive text, I still find them difficult to differentiate and almost impossible to casually scan. Thus, my first suggestion is to add some form of categorization to the item types. For this to function correctly, the GUI will need to be smart enough to apply the categories only when item counts are sufficient to justify them (if you only have 4 item creation types, it doesn't make sense to have 8 categories with which to sort them). But if you are a long time Jenkins user with many plugins you may also know it is possible to have more than a dozen item types. So if nothing else, an extension point that allowed for the categorization of item types seems helpful.

The configuration form itself, it also can become incredibly long with few landmarks or visual differentiation points. As a remedy, I propose calling out and clearly boxing each of the existing configuration sections and making sure that their names are as meaningful as possible. As an added step, I make the sections collapsible. This allows the user to jump to specific points in the form and tuck other areas out of the way. In some cases, we can make specific sections open by link context or even by user context.

Plugin Selection

Another essential piece of the Jenkins experience is plugin configuration. Today, if you are looking to add plugins to your Jenkins environment, you are almost certainly using Google to find a 3rd party review site, collecting the name of the plugin you want and then either linking to it on this website, or filtering for it in the Plugin Manager GUI.

Neither in the product nor on this website is there a particularly good resource for comparing plugins and evaluating which you might add.

Instead, I am looking to add something akin to an application store experience to both this website and the product UI. You should be able to group sort and compare plugins by a variety of criteria, including author, installation base, and user review. You should also have a set of general use categories that fits user needs and expectations, rather than the free ranging labels that plugin authors have arbitrarily applied today.

Workflow Script Builder

Finally, I have a GUI that allows for a sort of Drag-n-drop assembly of Workflows. A major tenant of the utility of Workflows as opposed to Freestyle jobs is that they can be completely separated from the Jenkins GUI and stored in a source repository. None-the-less, with absolutely no GUI, there is little to guide the user who is looking to get started without a upfront learning investment. As it turns out, a Workflow/Groovy script is pretty straight forward, but you don't really know that until you have made one. Also, Workflow allows for the orchestration of jobs across multiple nodes of hardware resources, making it a potentially involved little bit of configuration. Thus, my goal here is two fold. Allow the user to model a workflow quickly and easily and showcase a few of the more advanced features workflow enables. The result is this script builder. My hope is to host the prototype somewhere you all might be able to use it directly, but in the meantime, my hope is that my video pretty well explains how it works. Please take a look and post whatever comments you see fit.

...and really send along feedback...

So with all things community related, please, please, send back whatever feedback makes sense. I can be reached via Twitter @gusreiber.

Other places you can find me include, IRC (freenode/#jenkins) and Google+ ( I would love to hear from you.



Questions and Answers from the talk:
  1. How likely is it that any of these UI changes will make it into the core open source Jenkins? When would we start seeing them there?
    Most will be OSS. An exact schedule has not been determined, but most of it is still about a year away. Likely we will have an experimental wars for download along the way.
  2. Is there anyway to determine which GUI attributes are contributed by which plugin?
    I take it that is a bit of a feature request? It came up at JUC West as well. Should be something that can be surfaced in the GUI. I agree, it would be helpful.
  3. What is the difference between ANT and Jenkins?
    Ant is a good bit more bare-bones than Jenkins. In fact, you can add an Ant plugin to your Jenkins environment. You would typically use Ant to compile java source files. Jenkins orchestrates the fetching of the source files from some particular repository, the building of those files (often Jenkins uses Ant via its plugin to do this), running and reporting some suite of tests against that build, and then archiving or deploying the artifacts to wherever. Often times this requires navigating several computers with their own security constraints, so Jenkins helps you manage that as well.
  4. What version of the Jenkins it is?
    This isn’t available today, but I am building against 1.621-SNAPSHOT currently, but will upgrade with Jenkins to the coming December LTS. I'm interested in seeing the list of 100 plugins that you mentioned (by Daniel?) Me too. :^) He and the community (which can be you if want to join IRC and attend the hangouts and governance meetings: )
  5. For IRC, I assume the server is
  6. Will there be any dashboard kind of feature for the build history in the new GUI?
    So far, I have been focusing on the create and configuration portion of the Jenkins UX as I see it as a barrier to entry for new users. The read/report/analyze half of the Jenkins UX I actually see as the portion with more long term value, as you tend to read more often than you write, so I am eager to jump in here as well. ....however, in its core today, Jenkins the tool seems to me to really want to see the world in the same context of flat XML files in folders as it actually persists its configuration data. To really make meaningful dashboards, it needs to be possible to query job configurations and build artifacts by a wide set of criteria that is not at all related to the folder in which the xml file happens to be stored. Also, some of the things you care about in the Jenkins universe are compute resources (masters/slaves/exactures). These are also not the same as config files in folders and need to be queryable as their own first class type of entity. what I am saying with a lot of words is that I see the config piece as a somewhat more immediate and urgent fix. The broccoli of the meal, if you will. I will want to get that out as fast as possible to get it out of the way. The reporting piece is actually the wine. At the moment, we are giving you Bartles and Jaymes in paper cups. a lot of work is still needed there.
  7. Have you investigated Google Polymer as UI components for jenkins UI?
    I have not, but will now. I am actually quite a google fan-boy in much the way a lot of kids love Apple. (I also love Apple… being from Seattle, I even love MS). But, for the super near term, we are most focused on getting JQuery cleanly into core and Prototype.JS deprecated. Walk first, is my feeling.
  8. Are there any tutorials on Jenkins workflow?
    Jesse Glick or KK are better people to ask about that, really. They are also on IRC: Daniel Beck as well, might be a good person to ask. My little workflow demo is still really just fiction. Will there be a 'Expand All' and 'Collapse All' buttons for the accordions in new configure GUI? (I would probably inject one if not by default) Yes. Also, they should be URL controllable so that they can be set by link or user context easily. Maybe they should also remember what you had open last? ...stuff to tinker with that really needs to be right.
  9. What impact does the UI changes have on job configuration behind the scenes? Is configuration still stored in XML format?
    None. The post string stays the same and from then on, Jenkins is Jenkins.
  10. Can the create item screen be configurable? At the moment, no, but ideally yes. It is still a big hand wave at the moment about how those categories are created, managed, and updated. The same categories ought to bubble back up when searching for the plugins to help relate what plugins generate what UI. I am hoping for guidance from the community. How will workflow fit in with new UI?
    In some respects, the new configuration page is about enhancing the more traditional freestyle job and not workflow. However, the last bit of my presentation with the script builder is exclusively about workflow. The plugin manager is about plugins, so it would apply to both.
  11. How is a human notified for the wait for approval step in this workflow?
    So workflow approval can be done via the web GUI. But to get real notification, you would program that into your workflow Jenkins has a fairly large set of notification plugins. So you can use Jenkins to trigger email, or SMS, or HipChat, or Slack, or pretty much whatever. As these plugins are increasingly customized for workflow, you will get nice and nice workflow syntax for instantiating those actions. When my script builder is adopted, you would have a friendly button you could drag into the stage and it would notify you prior to the manual checkpoint.
  12. Custom plugins still supported?
    Yes. Though there is supported and supported. The highest level of support for a plugin would be a custom DSL for workflow that would make for streamlined syntax in workflow for interacting with that plugin via Groovy. But existing plugins do not need that level of support to be used within a Jenkins file / Groovy script. Instead, the syntax for accessing the plugin is likely to be more complicated. ….some plugins are freestyle specific, in which case, they no longer make sense in workflow. ….Daniel Beck or Jesse Glick are probably better suited to answering this question, however...
  13. Will there be an improvement in performance with docker builds, sonar scanning? From my experience sonar takes 20+ mins with jenkins plugin where as it takes 3 mins with maven plugin
    Is this times it is taking the GUI to render, or the actual build to run? I am not sure I am following the question exactly, but regardless, I am not well equipped to answer many questions about performance issues in Jenkins. I know of a fairly major performance issue specifically in the configuration form that I believe will be fixed in the new GUI, but that isn’t build performance, it is just form rendering performance.
  14. I like the graphical configuration. Thanks. The scripting of a complex workflow looked a bit daunting.
    Cool. Yeah, my main and first goal is to get something out there that would allow folks to quickly sketch and deploy an actual working workflow that reasonably reflects an 80%ish use case. No GUI can ever be as fully flexible as a script, but I don’t think most people need the 95% case to get started and see the benefit of a versionable and robust config file format.
  15. Will there be any effort to make the UI mobile friendly for the admin on the go?
    Absolutely. Especially on the TBD read/reporting end of the UI, but everything new needs to meet a reasonably high bar of device responsiveness. Today, the Jenkins GUI is just not responsive. Which is terrible.
  16. As a plugin developer do I need to change implementing the ui source from jelly or groovy to some other language/technique or will it be compatible?
    So you will not NEED to change from whatever you are doing, except if you have built a plugin GUI that has custom script that either relies directly on behavior.js, hudson-behavior.js, or the particulars of the existing DOM structure (you do something in the client that requires your or some other input to be in a particular TABLE TR TD DOM traversal path). ...I believe 2 things are going to continue to happen at a faster and faster rate. New plugin authors are not going to want to write GUIs in Jelly and Prototype.js, but instead use some more modern client side MVC approaches like Angular, where the GUI interacts with a REST api instead of being a dom directly rendered from the server. It is a bit of a different mode of working than Jelly, and maybe slightly less direct, but it is a lot easier to find doc on how to do things with JQuery, Agile, Handlebars and the like, than it is to find doc on Jelly. And the responsiveness and breadth of gestures and controls in Jelly are already terribly behind what is now the main stream of web UI development. So I think plugin builders are, if they aren’t already, going to want better tools available to them. I also think that people are going to gravitate towards workflow or something similar. Since the UI for workflow is foremost a script, making a GUI for a plugin that works with it might be a fundamentally different beast. ...depending on what the plugin is trying to do… So again, new plugins or even upgrading existing plugins to work with workflow are likely want a new technology set, not just because the existing Jenkins GUI is changing, but because new plugins will want to do different and better stuff.
  17. Are there connectors for other source control tools like CVS and Dimensions?
    I am not sure exactly which connector plugins are already supporting Workflow or how deeply that support goes. Because Jenkins has plugins that provide access to these SCMs, you can use workflow to go and fetch those source trees. A greater level of support for workflow from these plugins would mean a more elegant workflow syntax for that interaction. At the moment, my GUI script builder is still fiction. My plan would be to add GUI buttons for whatever are the most popular SCMs and I will attempt to mask the syntax regardless of its clumsiness. ….the way I am constructing my initial prototype, there is already a reasonably clear extension point for adding buttons that generate some chunk of Groovy syntax when it is dragged into a stage. So I will add the initial set based on community feedback and then the community can continue to add their own.
  18. What are the compatibility issues existing plugin developers needs to be aware of?
    For plugins that interact with freestyle jobs, or really most job types that aren’t workflow, plugin developers should expect the page DOM structure to change. If for whatever reason, they find they are busting into some custom script to traverse the DOM to compare 1 setting to another, that will break. Also, hudson-behaviors.js itself has a number of functions in it that do DOM traversing, like “findFollowingTR”. In some cases the signatures of those functions might need to change and the DOM structure that they return might also change. If a plugin uses what were meant to have been internal functions, they are likely to break. Finally, the page geometry is going to change. This may seem so superficial and obvious that, who cares, but sometimes changing a column width translates into an important part of a GUI being hidden or otherwise inaccessible. That ends up being as critical a break as any other. to combat these points of possible breakage, we are going to be looking for a handful somewhere between 20 and 100 plugins that we will want to test against. We haven’t made that list yet, let alone run any tests, so that is really a critical next step. For the plugin manager changes, I don’t see much if any of a braking issue, although I would like to add additional sorting and display power to the GUI, which means the GUI will need more metadata than currently exists, if the plugins want to take advantage of that new power in the GUI. This won’t break things, but plugin authors might want to go back to their plugins and fill in whatever the new bits of metadata end up being…. most likely they would be things like, richer descriptions, better category selections, and possibly icons.
  19. I've not seen a lot of Jenkins but what I had I didn't really get, was awkward for all the reasons Gus mentioned. This looks brilliant. When can we have it?
    Tom and I, and now our junior pledge, Keith (not actually junior at all, just more fit than me), are busily typing as fast as we can as well as lobbying the community that our vision is more or less a correct one. We have a very interesting initial plugin selection GUI that might make this years final LTS (which I did not demo), which is none-the-less a nice step forward for Jenkins. In it will be a lot of the JS library bundling that will enable most of what I have shown in this demo. Our hope is that with each LTS we will be able to push out an additional piece of the GUI puzzle. Likely starting with the job create and configure GUI, which would be the mid year LTS. I am hoping that a year from now this will be how Jenkins looks and acts. ….in the meantime, we are grappling with how best to push preview releases so people can play with it and send me hate mail.
  20. Is there any way to test front end of Jenkins plugins? And will that improve too?
    A major and almost blocking portion of this work used to be the custom and somewhat broken version of HTMLUnit that was in core, which greatly hampered including libraries other than Prototype in Jenkins and writing code using those libraries in some sort of testable way. Our new approach to rebuilding the Jelly controls which are the foundation of the Jenkins config page and in general are shared by all plugins that need to post data back to Jenkins, already have a testing strategy backed into our design. Those Jelly form controls are extensible in Jenkins today and would remain so. Our hope would be that any plugin adding custom controls would follow our same design and test pattern we are building in core. ….so that was a long answer, but the short answer YES! Today, building GUI parts into your Jenkins plugin is a bit of a mystery, where most people copy something they saw someone else did, hack it, and the only test is, well…. it worked for me. That is no good and a fundamental piece we are looking to change. ….still a long answer… Node.js and Jasmine are the specific tools we using.
  21. What's the estimated rollout date for this workflow feature?
    The workflow feature is the newest concept I demonstrated, but in a lot of ways may also be the easiest to ship. As a script generator, exclusively, it could be hosted anywhere, and then you just paste your generated workflow script into the whatever existing Jenkins GUI better, submit into your source code. ….but at the moment, it isn’t actually on an official roadmap yet. Assuming the response to it remain positive, I would expect that to change fairly quickly.

Office hour on form handling in Jenkins

Sat, 2015-09-19 18:36

Update: This week's office hour has been canceled.

This Wednesday, Sep 23, at 11 am PDT I will host another office hour on Stapler, the web framework used in Jenkins. This time, I'll show you how structured form submission in Jenkins works, and how Stapler can help you with it.

As usual, the office hour will use Hangout on Air, and a limited number of people will be able to join and participate. The others will be able to watch the office hour live on YouTube. Links to participate and watch will be posted before the event on the Office Hours wiki page.

Update: This week's office hour has been canceled.

Jenkins and Powershell Remoting on Windows

Wed, 2015-09-09 09:09
Welcome to the latest JenkinsHeaven post! Requirement

Auto deployment of a database as part of the build to SQL Server on a remote machine running Windows 2012 R2.

As the application database has views and (at time of writing), DBMigrations does not support views it was decided that we would use Powershell to execute SQL scripts against the SQL Server on the remote machine.

So Jenkins needs to execute Powershell and it needs to execute on a remote machine.

Let's break it down and build it up.

Install the Powershell plugin from the update center.

First we need to prove connectivity. Let's just squirt a file from Jenkins to the remote machine using powershell.

Follow the instructions here to test powershell is working locally on the Jenkins machine.

In Part 2 here, we don't need to do all of it. Let me elaborate.

  1. The "Using SSL on the Jenkins Web Interface" section is optional. I didn't have to do this to get connectivity working.
  2. Set up trustedhosts as per the "Configure the Jenkins Server for Remoting and Script Execution" section. I executed Set-Item WSMan:\localhost\Client\TrustedHosts -Value myserver in the Powershell console on the remote machine specifying the IP address of the Jenkins box for myserver
  3. Additionally, make sure you change line 10 of the Powershell script to use your username (don't forget the domain prefix if you need it.) and specify the correct name of the credential on line 6 that you would have set up in the Global Passwords step earlier. NB. Global Passwords are now under Jenkins > Configure System

Next, we need to open the firewall on the remote machine. Search for "Windows Firewall" and open Windows Firewall with Advanced Security

For each of the following rules:

  • Windows Remote Management - Compatibility Mode (HTTP-In) - Domain
  • Windows Remote Management - Compatibility Mode (HTTP-In) - Private, Public
  • Windows Remote Management (HTTP-In) - Domain
  • Windows Remote Management (HTTP-In) - Private, Public the following:

  1. Enable the rule; and
  2. Right click, Go to Properties > Scope and select "Any IP Address" option in both the Local IP Address and Remote IP Address sections.
5. Open the Powershell command prompt on the remote machine and as per this execute Enable-PSRemoting -Force.

You should now be able to execute the "Create Text File Remotely" job on Jenkins and see the output on the remote machine.

Office hour on proposed UI/UX changes

Mon, 2015-09-07 07:53

Gus Reiber will host this week's office hour on Wednesday, 11 AM PDT. He'll talk about some of the UI/UX improvements in Jenkins that he's working on, and will answer your questions about it.

He's already given several talks about this, so you can check these out to learn more before the office hour:

There are also some mailing list threads where he's discussing his designs with the community:

The links to the Google Hangout (participate) and Youtube (watch live) will be posted to the wiki before the event. If you don't get into the Hangout (limited number of participants), don't worry: You'll be able to send questions and suggestions to his Twitter account @gusreiber.

Office hour on proposed UI/UX changes

Mon, 2015-09-07 07:53

Gus Reiber will host this week's office hour on Wednesday, 11 AM PDT. He'll talk about some of the UI/UX improvements in Jenkins that he's working on, and will answer your questions about it.

He's already given several talks about this, so you can check these out to learn more before the office hour:

There are also some mailing list threads where he's discussing his designs with the community:

The links to the Google Hangout (participate) and Youtube (watch live) will be posted to the wiki before the event. If you don't get into the Hangout (limited number of participants), don't worry: You'll be able to send questions and suggestions to his Twitter account @gusreiber.

Integrating TFS with Jenkins

Sun, 2015-09-06 03:20
Hi Everyone,

As you all know I'm no great fan of TFS. Since I last talked about TFS things have improved somewhat.

Let me tell you a brief story.


Two weeks ago I was doing a very quick engagement for a utility company, mostly to help out a friend more than anything. The engagement was only for three days. As they had no CI capability I set up a Jenkins box and tried to integrate with the Bonobo Git server on the same box. Jenkins failed check it out the code...we think because certificates needed to be set up. Due to time constraints we got approval to move the code to a private GitHub repo. Problem solved.


Just this week, at my latest engagement (in the same building I'd just left 3 weeks earlier but that's another story!), I was confronted with a TFS server and a request to set up a CI build. I recommended Jenkins and Git. I expected they would take more convincing to move away from TFS as a build server, however fortunately they did their own research and came around to my thinking that TFS as a build server is just not as good as Jenkins. The difficult part was that private GitHub repositories would not be allowed in this corporate environment. (This corporate is very behind the times!)


We struggled for a couple of days to setup a git repo we could control in the (overly locked down) dev environment that we had been given. In the end we abandoned this endeavor...we tried all manner of things, even a git backed repository in TFS 2013...just too hard.

I thought I'd take another look at the TFS plugin for Jenkins and was very pleased to see that it has recently been through a major rewrite. Version 4.0 of the plugin was released on August 27th, 2015....and it works!

The trick is to get the settings "just so".

  1. In the job config select the Team Foundation Server option from the Source Management section.
  2. In the Server URL field enter https://<tfs-server-name>:<port>/tfs/<collection-name>
  3. In the Project path field enter $/path/to/root/of/my/solution
  4. In the User name field enter the user name that has access to TFS
  5. In the User password field enter the password associated with the user name

I didn't enter anything else.

Points to note:

  • The Server URL has to be html escaped. So, for instance my <collection-name> had spaces in it, so My Collection Name becomes My%20Collection%20Name. If your <tfs-server-name> or <collection-name> has other special characters they will also have to be correctly escaped.
  • The User name doesn't have to be an email address. In my case it wasn't.

If you don't get the above settings correct (I initially didn't know I had to include the collection name), you'll probably get an error such that it can't find a SOAP endpoint.

Get it correct, however and BAM! your Jenkins workspace will be populated with your source code.

Now it is easy integrate Jenkins with TFS such that you can get the code out of TFS and work with it in a Jenkins build.

Hopefully this has been helpful to someone out there. Let me know in the comments. I always like to hear your feedback.

Till next time...

Jenkins User Conference West Day 1

Thu, 2015-09-03 07:55

Boy, what a day! This is the 5th annual JUC in San Francisco bay area, and the crowd is getting bigger.

I brought the LEGO Jenkins + CloudBees logo mosaic that we built at the CloudBees San Jose office:

The community booth was very busy. We have people like Dean Yu (board), Andrew Bayer (board), Mark Waite (git), Jesse Glick (workflow and core), Daniel Beck (core), Vincent Latombe (literate), Steven Christou (subversion) and Owen Mehegan (community outreach) talking to people all day long.

If you are here, make sure to stop by, and if you are not, follow news with #jenkinsconf.

Take the 2015 Jenkins Survey!

Tue, 2015-09-01 15:34

Just as in past years, we are running a survey this year, to get some objective insights into what our users would like to see in the Jenkins project. Obviously, the developers in the project deal with individual bug reports and feature requests all the time, but sometimes those day-to-day issues distract you from a bigger picture.

This year, we kept some of the questions the same, so that we can see the trend over time. But we also wanted to bring in some questions around how you are using Jenkins and what other technologies you leverage such as Linux containers and cloud services.

The survey will close at the end of September and, if you participate, you'll get to see the results first. CloudBees is sponsoring the survey and as an added incentive for us to fill it out, CloudBees has pitched in a $100 Amazon gift card (thanks CloudBees!). Information you submit is only going to be used by the community and not by CloudBees. So please take the survey and let your voice be heard.

Finally, there are laws that govern prize giveaways like this and Cloudbees has put up terms and conditions for this.

Take the survey here

Jenkins CIA Program and Meetup Updates

Mon, 2015-08-31 17:21

A few years ago, the Jenkins community announced the Jenkins CIA program - the Continuous Integration Ambassador initiative to spread the word of Jenkins. As of recently, there hasn't been as much activity, so this program needs to be revived!

There are over 120,000 active Jenkins installations now and that number just keeps climbing and climbing. It's important to bring all of us together through big events like the Jenkins User Conference, but not everyone can get there. That is why Meetups and smaller Jenkins events are crucial.

To support this effort, CloudBees has announced that they will be sponsoring the kickoff of the CIA revival/JAM to help the Jenkins community host these Meetups!

To kick this off, the first Jenkins Area Meetup (JAM) is in the San Jose CloudBees office on Sept 23. We are shooting to have a JAM everything 3rd Wednesday of every month to consistently bring the community together.

Plugin Spotlight: Version Column Plugin

Mon, 2015-08-31 16:58

Most Jenkins masters with a distributed build configuration will leverage nodes that run a slave.jar to start a slave agent. Regardless of whether the slave.jar is launched through a Java Web Start or SSH launcher, the jar will be copied from http://yourserver:port/jnlpJars/slave.jar to the build node. Keeping this jar up to date ensures that it picks up the newest features in a more recent release, such as the self-restart feature to keep slave JVMs “clean” and to automatically reconnect to their master. Additionally, newer versions of this component may fix bugs or implement newer protocol versions with various improvements.

What is the Version Column Plugin?

Launch methods designed to pull the latest slave.jar are not always reliable and some launch methods don’t even try to update the slave.jar. Therefore it can be useful to see what slave.jar version is running on a given build node and take offline any nodes which fails to update to the latest version of the jar.

The Version Column Plugin allows Jenkins masters to do just this, adding a new column to the “Manage Nodes” view and a new option for version enforcement on the node configuration screen.

Getting started

After installing the Version Column Plugin, navigate to the list of nodes in your Jenkins instance by clicking Build Executor Status in the executors widget below the side panel on the Jenkins home page.

If the plugin installed successfully, you will see a new column simply called “Version”. This column displays the version of the slave.jar that each build node is using.

This column is simply displaying the versions, so enforcement of slave.jar versions will need to be configured elsewhere. To activate this, click on the “Configure” link in the node manager’s left-hand menu.

You will then see a set of options for slaves. To activate version enforcement, check the “Version” box and apply your changes.

When you update Jenkins, there’s a chance it’ll come with a new version of slave.jar. Now if the slave.jar on a particular slave doesn’t get updated automatically, the master will take it offline and show a warning next to the out-of-date slave’s version number:

The Version Column Plugin is available for download in the Jenkins plugin manager or from its wiki page.

JUC Speaker Blog Series: Laurette Cisneros, JUC U.S. West

Mon, 2015-08-31 12:00

Last year's JUC West 2014 was packed with good gems of information – such as "how we did it" talks where the speakers shared their points of view on the tools they use for automating their pipeline. At JUC and other conferences I especially seek out talks about how others implement their Continuous Delivery processes. 

At the upcoming JUC West 2015, it is my turn to share “how we did it” at Perforce. I will present my talk "Continuous Delivery: Driving Lessons” and describe our journey, the rewards we reaped, and the challenges we faced along the way.

At Perforce, we see Continuous Delivery as taking the proven technique of automation and expanding it to a solid set of practices that make the pipeline even more efficient. This includes empowering the product teams to own production and quality all the way from requirements to delivery, and moving from a central build and release team to a self-serve infrastructure to remove the "friction" in the workflow. These changes have allowed us to quickly, efficiently and reliably adapt our software in line with user feedback, shifts in the market, and changes to the business strategy.

I look forward to seeing you there!

This post is by Laurette Cisneros, Engineering Tools Manager at Perforce Software. If you have your ticket to JUC U.S. West, you can attend her talk "The Road to Continuous Delivery: Driving Lessons" on Day 1.

Still need your ticket to JUC? If you register with a friend you can get 2 tickets for the price of 1! Register here for a JUC U.S. West, the last JUC of the year!

Thank you to our sponsors for the 2015 Jenkins User Conference World Tour:

JUC Speaker Blog Series: Jamie O'Meara, JUC U.S. West

Fri, 2015-08-28 10:50

Cloud Native and the benefits to Continuous Delivery (CD) Pipelines

There’s a lot of discussion lately around Cloud Native. If this term is new to you, I suggest a quick read of Cloud Native: What it Means and Why it Matters? From my perspective, Cloud Native offers tremendous benefit to enterprise companies, startups and developers looking to add value quickly or capture market share. Cloud Native platforms, such as Cloud Foundry, provide a number of features to reduce the effort of developing software and operating it on or off premise. A few notable features include load balancing, application routing, cluster scheduling, and containerisation. Cloud Native also offers a significant advancement for building integrated pipelines to deliver software. Before we discuss these advancements, let’s consider the role of the container.


One of the most influential components of Cloud Native is the container. At this point, containers are fairly ubiquitous and most developers have experimented or used containers. For instance, if you've pushed an application to Cloud Foundry or Pivotal Web Services, you’ve used an container without knowing it.

Initially containers were a place to automate the deployment and execution of your code, but over time customization became necessary to handle specific use cases. As a result, container creation now occurs earlier in the development and build phase. As applications are packaged within binaries and containers, validation of the application and container configuration needs to be validated before leaving the developer’s laptop. So what does this mean for the continuous delivery (CD) pipeline?

CD Pipelines

Developers will tell you their role has expanded over the years as agile methodologies have changed the way software is engineered. Techniques like Test Driven Development (TDD) and CD pipelines encourage software teams to deliver higher quality code in every build. Of course, a good CD pipeline starts at the developer’s laptop. Building and testing the start of a pipeline requires the correct tools while preserving the developer’s choice of container.

The diagram below demonstrates a simple CD pipeline. As you can see, the pipeline starts from the developer’s IDE and uses Cloud Foundry’s Latticeto provide a sandbox to validate the delivery artifacts. Lattice, based on Cloud Foundry’s container scheduler, delivers a small Cloud Native Platform that can be scaled up in the cloud or scaled down to a laptop. It includes a cluster scheduler, HTTP load balancing, log aggregation and health management for containers. Best part, it offers developer choice. Lattice provides support for both Docker containers and Cloud Foundry buildpacks.

Lattice’s flexibility makes it extremely easy to test how the application, which runs in a Docker container, will function in a Cloud Native environment. It’s also extremely helpful for developers engaged in a spike (prototype phase) where they want to push, validate and demonstrate code and let the platform handle the container creation, runtime environment and deployment artifacts via Cloud Foundry buildpacks.

Extending the CD pipeline beyond the developer’s laptop to deliver value to the organization will require additional tools like the CloudBees Jenkins Platform, Artifactory and Pivotal Cloud Foundry. These enterprise build-and-deploy solutions help developers deliver to a Cloud Native platform and reduce the time to establish the feedback loop. If the enterprise maintains a Hybrid cloud strategy, these tools make it seamless to deploy across different cloud providers.

As developers build more Cloud Native applications for Cloud Native platforms, it’s important to establish good tool chains and best practices early in the development phase. Interested to see these tools in action? Join us at Jenkins User Conference West on September 2nd to learn how I use these tools to build Integrated Deployment Pipelines with Jenkins and Cloud Foundry.

This post is by Jamie O'Meara, Field Engineer at Pivotal. If you have your ticket to JUC U.S. West, you can attend his talk "An Integrated Deployment Pipeline with Jenkins and Cloud Foundry" on Day 1.

Still need your ticket to JUC? If you register with a friend you can get 2 tickets for the price of 1! Register here for a JUC U.S. West, the last JUC of the year!

Thank you to our sponsors for the 2015 Jenkins User Conference World Tour:

Announcing the travel grant program

Tue, 2015-08-25 10:50

We're currently setting up a program to support community members' travel to Jenkins community events. Our goal is to enable more members of the community to meet each other and exchange ideas in person.

We're still hashing out the details, but it'll be available to every Jenkins community member. Apply, telling us what Jenkins-related event you'd like to attend and how awesome you are, and we may support your travel with up to 500 USD. For details on how this will work, see the current draft of the travel grant program.

The first person to be supported in this way is Pradeepto Bhattacharya from Pune, India. He was a speaker at this year's JUC Europe in London, and will give two talks at JUC US West next week—and we help him get there! He asked us a few weeks back whether the Jenkins project could support his trip to the US. We came to the conclusion that this would be a good idea—so good in fact, that we decided to build a regular program from it.

Are you planning to attend a JUC or similar event, but worry about the cost of travel? We may be able to help you out!

JUC Speaker Blog Series: Kaj Kandler, JUC U.S. West

Mon, 2015-08-24 08:32

Developing Enterprise-Ready Plugins

My greatest surprise at JUC 2014 in Boston was how many enterprise Jenkins CI users had developed plugins for their own use. I had not pictured enterprise release managers as plugin developers. Here at Black Duck Software, we developed Jenkins plugins for four years running. Fabrice Solami, a sales engineer, wanted to do more than automate our code scanning tool via a shell script step in the Jenkins job. He wrote a first plugin that added a build step to run the tool and configure the job more comfortably. The plugin became quickly popular, and when customers asked for it to also support maven builds and run on slaves, it was time for help from the engineering team, particularly the integration team I lead.

Over the years we developed four more plugins and overhauled the original one with the user community (aka paying customers) growing to >75 organizations, mostly large or really large development organizations. In the process, we received lots of feedback and discovered some Jenkins features we feel are essential for good plugin design for the enterprise. Let me share these insights so that you can consider them in your plugin development.

Credentials Plugin

Our plugins connect to our web applications and need authentication to utilize our SDK. The first plugins used username and password fields in every job configuration. That made tedious configuration work and stores the passwords in clear text in the configuration files on disk. Ouch!

We did wise up and started using the credentials plugin to manage username/passwords centrally and securely. It even allows setting authorization roles in such a way that the maintainer of a job can use the credentials without seeing the password. With that in place, our plugins are fit for banks and insurance companies and any other security-conscious organization.

Support the REST API

Did you know that Jenkins talks REST? We found it to be an easy way to create and update jobs. It is a really handy tool. The REST API is easy to script for all sorts of external interactions.

However, plugins need to do a little effort to support it on their part; yet it is almost trivial to do. So from our experience it should not be left out.

We wrote a small Java program that reads, creates, updates job configurations, and can trigger job runs. It reads the jobs and commits them to a file for easy mass editing and updates the jobs afterwards.

Our internal use case is to manage regression tests. We have medium-sized lists of jobs that run regression tests. With this tooling we can create a new set of jobs for a given plugin that runs against a new target server, that is, a server version under QA. It all happens in less than 15 minutes.

We also made this part of our migration from our first plugin to its successor with all the enterprise capabilities, but incompatible configuration. Using the REST API and some more Java programs we can create a csv file / Excel spreadsheet with jobs that are configured with the previous plugin. The user can filter the list with the spreadsheet application as needed, and then use the resulting list as input to the batch upgrade tool. This makes the upgrade a gradual affair and not a tedious exercise in UI configuration changes.

UpdateSites Manager Plugin

If you are developing plugins for in-house use, you have the option to install/update those through file upload. However, in an enterprise you likely have multiple Jenkins servers for different divisions, development groups, or regions. The notification of updates becomes tedious at best. Wouldn’t it be nice to run your own update site, so that your plugin(s) become discoverable in the “Available” tab of the “Manage plugins” screen? Wouldn’t it be a dream if available new versions show up automatically in the “Updates” tab, including Jenkins version compatibility check?

UpdateSites Manager plugin by IKEDA Yasuyuki is the answer to your prayers. It is easy to install, and the process to create and publish an update site is not too complicated and can become part of your Jenkins job building/releasing the plugin.

In my presentation at JUC 2015 West, I’ll share more details on how this makes a difference and how you can use these techniques to make your plugins enterprise-grade. As a bonus, I’ll show you how to get a free vulnerability report for your Maven or Gradle builds.

This post is by Kaj Kandler, Integration Manager atBlack Duck Software, Inc. If you have your ticket to JUC U.S. West, you can attend his talk "Making Plugins that are Enterprise Ready" on Day 1.

Still need your ticket to JUC? If you register with a friend you can get 2 tickets for the price of 1! Register here for a JUC U.S. West, the last JUC of the year!

Thank you to our sponsors for the 2015 Jenkins User Conference World Tour:

Upcoming office hour on Kubernetes

Thu, 2015-08-20 13:36

Nicolas De Loof will host an office hour next Wednesday 11 AM PDT on integrating Kubernetes with Jenkins. Kubernetes is an open-source project by Google that provides a platform for managing Docker containers as a cluster.

During this session, Nicolas will introduce Kubernetes, explain how it can benefit Jenkins and demonstrate the Kubernetes Plugin. Then he will discuss the design of the Kubernetes plugin and plans he has for future improvements.

Participate in the Hangout on Air or watch live on YouTube.

Volume 9 of the Jenkins Newsletter: Continuous Information is out

Thu, 2015-08-20 06:01

The Jenkins Newsletter is out a bit early this quarter. If you are not signed up to receive it via email, check out Volume 9 here.

You will be connected to all sorts of Jenkins resources from Jenkins training sessions, to some Jenkins User Conference news, to how Jenkins works with Kubernetes and Docker.

I hope that you enjoy this issue! Please let me know what content you find to be the most useful, reach out to me with content that you would like to see in the next issue, and feel free to tell me how I can improve the Jenkins Newsletter: Continuous Information. You can reach out to me at Thanks!

JUC Speaker Blog Series: Andrew Phillips, JUC U.S. West

Tue, 2015-08-18 08:51

Join Me at JUC West to Discuss Building an Enterprise Continuous Delivery Machine with Jenkins

After a great event on the East Coast in June, now over to the West Coast for another exciting Jenkins User Conference! I'll be there for JUC West on September 2-3 with the XebiaLabs team, and am looking forward to talking to the Jenkins users, partners, developers and community members that will be coming together.

At JUC East, I talked about the importance of Automated Testing in your Continuous Delivery pipeline, and I was really pleased by the number of interesting discussions and comments that came about as a result.

For JUC West, I'll be taking a broader view, and will talk about building an "Enterprise Continuous Delivery Machine" around Jenkins. I'm going to focus on the challenge of identifying and choosing solutions for the many "adjacent problem spaces" to Continuous Integration that you run into when trying to move to Continuous Delivery: artifact management, feature tracking, environment provisioning, deployment automation, test management, pipeline orchestration, production feedback and more.

We'll discuss some of the options available for each category, with a special focus on app deployment, test result management and pipeline orchestration. We'll also present a couple of real-world Continuous Delivery Machine architectures, and analyze some of the motivations for each organization's choices.

Most of our users use XebiaLabs tools/products in combination with Jenkins to build out their Continuous Delivery stack. If you’re scaling out your Jenkins usage too, stop by the XebiaLabs booth to see if you can pick up some tips and to say hello.

Look forward to seeing you at the event, or check the slides or recording we will post after the event. Hope to see you there!

This post is by Andrew Phillips, VP, Product Management at XebiaLabs. If you have your ticket to JUC U.S. West, you can attend his talk "Sometimes Even the Best Butler Needs a Footman: Building an Enterprise Continuous Delivery Machine Around Jenkins" on Day 1.

Still need your ticket to JUC? If you register with a friend you can get 2 tickets for the price of 1! Register here for a JUC U.S. West, the last JUC of the year!

Thank you to our sponsors for the 2015 Jenkins User Conference World Tour:

Update: Wiki and issue tracker outage

Thu, 2015-08-13 00:43

I recently wrote about the two day outage of our wiki and issue tracker:

While this was a rather lengthy outage, it could have been much worse. We lost none of the data, after all.

OSUOSL have since published their post mortem. I was really wrong about not losing any data:

A further complication was that our backups were pointed at mysql2, which was out-of-date with mysql1, due to the initial synchronization failures. Fortunately, we had the binary logs from the 17th through the 30th. This means that though most data could be restored, some data from between the 15th and the 17th was lost.

For our issue tracker, that means that issues JENKINS-29432 to JENKINS-29468 were lost, as well as comments posted from about July 15 12:20 PM to July 17 2 AM (UTC). We know this thanks to the jenkinsci-issues mailing list where the lost issues and comments can be looked up for reposting.

We unfortunately don't have such a record from our wiki.