Skip to content

Open Source

Cooking Up JAMs

There's been some active discussions and planning around Jenkins Area Meetups (JAMs) specifically in the following cities:

I wanted to gauge Jenkins interests in these cities, so let us know at if you live in one of these areas, and if you would be interested in becoming a member or be involved in JAM one way or another!

Of course, if the city you live in currently does not have a JAM and you're interested in paying it forward, here's HOW YOU can become a JAM organizer.

Categories: Open Source

Winners of Docker Global Hack Day #3 are...

Over 2,000 members of the Docker community attended Docker Hack Day events around the world. One of the forty-two Docker Hacks has some familiar names attached...

Nicolas De Loof and Yoann Dubreuil from Docker Rennes, who are also active in our community, waved the Jenkins flag in this event and produced Jenkins docker slaves plugin.

This plugin lets you run builds inside containers, and in that sense it's similar to the Docker plugin and the Docker custom build environment plugin. But internally it uses a quite interesting approach.

This fresh new implementation relies on a set of docker containers (aka ‘pod’) to setup a build executor, letting development team customize the build environment for their need without any constraint or prerequisite, and relying on docker containers to host test resources.

This project won the 3rd place in the Freestyle category of Docker Hack Day. Congratulations to Nicolas and Yoann on their win! Jenkins + Docker is a winning pair and this plugin will make a huge difference in your projects.

Categories: Open Source

Upcoming in office hours: Jenkins 2.0

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.

Categories: Open Source

Mainstream: Noun. The principal or dominant course, tendency, or trend

Sonar - Wed, 09/30/2015 - 22:13

At the SonarQube Geneva User Conference last week I learned that 7 of the Fortune 10 companies and 47 of the Fortune 100 use the SonarQube platform. We’ve got an estimated adoption of 50,000 companies overall (based on the number of unique IP’s that hit the update center). The figures really struck me because I’d never realized before how mainstream the platform is.

At my previous job, there was a lot of discussion about adopting a standard tool set. The logic went that standard tool sets are easier to hire for than home-grown frameworks. Not only that, but it’s easier to keep up with the pace of change if you’re using the standard; for any given technology change, you simply do the normal upgrades everyone else is doing, rather than having to re-engineer your stack, and wonder if you’ve covered all the bases.

That’s why an adoption of 50,000 companies – more than 20 times the adoption rate of our all our competitors put together, I’m told(!) – caught my attention. If you assume an average of 40 developers and development managers at each company, that’s 2 million people using SonarQube today(!). And that doesn’t even count the contributors to open source projects that track their code quality on nemo, the demonstration instance of SonarQube.

That means that if your company is using SonarQube, your chances are good that any new hires will already be familiar with it. You’ll have to train them on your expectations, but not on the tool itself.

At my last job we wanted to adopt the standard tools. At SonarSource, we are the standard tool. That’s pretty cool.

Categories: Open Source

Bay Area JAM

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

Categories: Open Source

GUI improvements on the horizon

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.
Categories: Open Source

Office hour on form handling in Jenkins

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.

Categories: Open Source

The Agenda for the Geneva Conference is Available

Sonar - Fri, 09/11/2015 - 15:02

The Geneva SonarQube is going to take place on 23rd-24th of September in Geneva and it is still possible to register

We want this 2-day conference to be very valuable as possible for participants, therefore it took us a little bit of time to put it together, but we believe we have a great agenda for the conference.

Categories: Open Source

Office hour on proposed UI/UX changes

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.

Categories: Open Source

Office hour on proposed UI/UX changes

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.

Categories: Open Source

Jenkins User Conference West Day 1

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.

Categories: Open Source

SonarLint for Visual Studio 1.2.0 Brings Code Fixes to the IDE

Sonar - Thu, 09/03/2015 - 16:36

SonarLint for Visual Studio version 1.2.0 was released this week. In this version we focused on improving the user experience by adding code fading and fixes. Code fading makes some issues less obtrusive, and code fixes are concrete suggestions for solving specific issues in the code. This means that when an analyzer identifies an issue in the code, the IDE can propose an automatic fix for it. We’ve added fixes for 17 rules, and the best part is that the user can choose to fix all issues of the same type all at once for the whole solution, which can immensely speed up paying down technical debt.

Analyzers and code fixes are integrated into Visual Studio 2015 natively thanks to Roslyn. As you would expect, the issues we raise show up in the Error Window. As part of improving the user experience, now some issues on redundancies or useless code just show up as faded text (note the fading in the image below). So these less serious issues aren’t uselessly cluttering the Error Window any more.

Redundancies fall into the “easy to fix automatically” category. For example, for the above issue (Rule S3254) we could simply remove the redundant code. In Visual Studio, to check and accept the proposed code fix, you should hover over the issue location and expand the lightbulb tooltip. Or you can move the caret to the line of the issue, and hit Ctrl+. (There is a good video on Channel9, which shows the navigational shortcuts in Visual Studio 2015.) The tooltip window contains all the available options for the issue. There can be multiple possible fixes for an error, so you can choose which one to apply. For the above case, there is only one fix, which is to remove the redundant arguments. Also note in the image below that at the bottom of the preview window you can choose to apply this fix to all issues in the document/project/solution.

One of my favorite code fixes is the one that simplifies conditional statements. Consider the following code, where the true and false branches of the conditional statement are very similar.

Here, the code fix for Rule S3240 proposes using the ?? (null-coalescing) operator instead of the 8-line conditional statement. The code fix provider is clever enough to recognize that this if can be simplified to ?? and not just to the ?: (ternary) operator, and it only proposes the simpler one.

These are just two of the new code fixes. There are 16 more available (one rule has two fixes). We also added two new rules and fixed some bugs in this version. You can see the full list of rules at the new version-specific landing page. A slight restructuring of the SonarLint website, means that each release now has its own landing page, which summarizes the changes since the previous version.

Categories: Open Source

MSBuild SonarQube Runner now available on Visual Studio Online

Sonar - Wed, 09/02/2015 - 09:13

The MSBuild SonarQube Runner TFS 2015 Build Tasks are now available out of the box on Visual Studio Online, and even on Hosted Build Agents! This means that SonarQube analysis can now be enabled in a few clicks on any Visual Studio Online project without having to install anything!

I could tell you more, but Jean-Marc Prieur from Microsoft has already done such a beautiful job that you should just read what he wrote in his Visual Studio ALM blog post.

Categories: Open Source

Take the 2015 Jenkins Survey!

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

Categories: Open Source

Jenkins CIA Program and Meetup Updates

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.

Categories: Open Source

Plugin Spotlight: Version Column Plugin

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.

Categories: Open Source

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

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:

Categories: Open Source

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

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:

Categories: Open Source

Announcing the travel grant program

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!

Categories: Open Source

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

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:

Categories: Open Source