SCaLE 14x Conference Report

Historically January has always been a very big month for the Jenkins community. Between FOSDEM Southern California Linux Expo (also known as SCaLE) we seem to hand out more stickers during the last week in January than any other week of the year.

This year’s SCaLE 14X conference finally outgrew the LAX Hilton in Los Angeles, where it had been hosted in years past, and moved over to the Pasadena Convention Center in Pasadena California. While the organizers of the conference expanded their scope, so did the Jenkins project!

In addition to our normal Jenkins stickers, we also had some special edition stickers with special logos to give away this year, namely:

  • Angry Jenkins

  • General Jenkins

  • Superhero Jenkins

  • "Cute" Jenkins

  • Ninja Jenkins

To accompany the stickers we also had both blue Jenkins and red "Angry Jenkins" pins. Savvy Jenkins users might recognize "Angry Jenkins" from the Jenkins server’s internal 500 page; fortunately however very few people that came by the booth to say hello were familiar with Angry Jenkins.

Talking Points

Aside from talking about the cool stickers and pins, we spent the vast majority of time talking about Jenkins to two groups of people:

  1. those who never had actually used Jenkins, even if they had heard of it

  2. users who knew plenty about Jenkins but hadn’t actually heard about some of the Jenkins 2.0 Proposals.

Anecdotally, it seemed like most of the people that I talked to about "Jenkins 2.0" were pretty excited about the Jenkinsfile idea and starting to define their build processes and delivery pipelines as code in their source repositories.

Perhaps more importantly though, we spoke with many users about where Jenkins is causing them pain or frustration. Speaking directly with users at events like SCaLE or Jenkins Area Meetups is always fun, having a high-bandwidth conversation about what we can do better and/or offering solutions/workarounds to hopefully relieve some pain-points.

In one such case, a contributor approached me and complained that he had emailed the developers' mailing list and frustratingly never actually received a response. Comically enough, neither of us were able to find the email he had sent the mailing list (whoops!) but because of the dynamic nature of booth-duty at SCaLE, we got him squared away with a repository to contribute a Jenkins Charm for the Juju configuration management tool.

Jammin'

Among the booth-duty highlights was meeting a few folks who were interested on starting a southern California Jenkins meetup. Over the days following the conference, and a brief discussion on the jenkinsci-jam@ mailing list, and the Los Angeles Jenkins Area Meetup was born!

I’m looking forward to the meetup growing over the next couple months and helping build a stronger local Jenkins community in Southern Califonia for the other 51 weeks a year that SCaLE isn’t happening.


SCaLE is one of my more favorite open source conferences, the positive community in attendance, a kid-friendly atmosphere ("Game Night" was a blast) and the broad spectrum of sessions available make it a great way to spent the weekend in southern California.

We hope to see you there again next year!

Jenkins World 2016: Call For Papers Is Open!

This is a guest post by Alyssa Tong. Alyssa works for CloudBees, helping to organize Jenkins community events around the world.

Jenkins World 2016

Planning is underway for Jenkins World, a major Jenkins event for developers, release engineers and others interested in automation. The conference will be held from September 13th to 15th in Santa Clara, California and is being organized and sponsored in part by CloudBees. Just like the "Jenkins User Conferences" before it, this year’s event will feature many experts from the Jenkins community that help make Jenkins the most popular open source automation server on the planet. We’ve found that we outgrew the popular multi-city one-day Jenkins User Conferences, so unlike previous years Jenkins World will be a three-day event in one place with an incredible amount of great content.

The goal of the event is to bring Jenkins contributors and users of all levels together, from around the world, to discuss, share and learn from one another. Starting today we’re opening the call for proposals. As a global event, users from all over the world are encouraged to submit a talk between now and May 1st, 2016 (11:59pm PST).

We look forward to receiving your amazing submission, and seeing you in Santa Clara this fall.

Office Hour: The State of JavaScript in Jenkins

Tom Fennelly will host tomorrow’s office hour on JavaScript in Jenkins. The intended audience for this presentation is core and plugin developers. In his own words:

I believe strongly that we can make meaningful user experience improvements to Jenkins, but it will require having more weapons in our arsenal in terms of how we build plugins etc. This is what we’ll be talking about in this week’s office hour. It will be a developer-focused session where we’ll start off by talking a little about how UI development has traditionally been done in Jenkins, before moving on to some newer patterns and tools that we have been developing over the last few months that let us make use of a wider range of more modern client-side development tools. We’ll also dissect and run some sample plugins that show these newer client-side dev tools in action.

As usual, the session will start 11am PST. Links to watch and participate will be posted to the Office Hours wiki page before it starts.

A beautiful Jenkins dashboard

This is a guest post by Julian Kleinhans, Software Architect at AOE, who is outlining some of the Jenkins dashboard work he’s done with dashing-js

Jenkins offers a handful of third party dashboards, but none of them are really beautiful and flexible enough from my point of view. For example, I could not find a solution which gives me the possibility to easily decide which data should be display in the widget and which not. It also doesn`t have the possibility to add additional widgets to the dashboard which have nothing to do with Jenkins. So I came up with something interesting that includes Jenkins data. But I cannot do that with the existing built-in dashboards from Jenkins plugins which are Jenkins-content specific.

So I decided to write a new, flexible and extensible dashboard. To avoid re-inventing the wheel I also decided to use dashing-js as a basis and not Jenkins itself. dashing-js is a Node.js port of Dashing, a Sinatra-based framework that lets you build beautiful dashboards.

The key features of Dashing are:

  • Use pre-made widgets, or fully create your own with Sass, HTML and CoffeeScript

  • Widgets harness the power of data bindings (via batman.js) to keep things DRY and simple

  • Use the API to push data to your dashboards or make use of a simple Node.js script for fetching data

  • Drag & drop interface for re-arranging your widgets

The advantage over a native Java-based Jenkins plugin is that you don’t need to know Java and the whole Java stack. You can also easily add other pre-made third-party widgets, for example a GitHub Pull Request count widget or an AWS statistic widget or whatever else. In other words, it is completely independent of Jenkins. All you need is Node.js and the permission to access the Jenkins API.

Beside dashing-js you will need my Jenkins Job widget. It is a generic widget for Jenkins jobs which provides a highly visible view of the build status and build progress of selected Jenkins jobs. Via configuration it is possible to add multiple widgets for different Jenkins jobs (as you can see in the screenshot below).

So, all you need is dashing-js, my Jenkins Job widget and some npm packages. The installation and the setup is really easy and can be found here.

Example

Example

Jenkins Code of Conduct

Over the past couple months, we have been working on a long overdue Code of Conduct for the Jenkins project (meeting minutes here and here). Following in the footsteps of other projects like the Apache Software Foundation, Go lang and countless others, we have adopted this code of conduct to help set guidelines for what behaviors are acceptable, and what behaviors are not, when acting within the Jenkins community or on behalf of the Jenkins project.

I would like to extend our gratitude to the authors of the Contributor Covenant who provided us with a very good and mostly finished Code of Conduct template. We have adapted the covenant to meet the unique needs of a multifaceted project like Jenkins.

The document itself is broken down into three sections, all of which I encourage you to read:

Similar to many other process and philisophical documents in the Jenkins project, the document is not etched in stone and is therefore intended to be updated. If you’re interested in participating in the discussion about this, and other topics around how the Jenkins project operates, I invite you to the #jenkins-community IRC channel on the Freenode network or to our regularly scheduled governance meetings.

A new Jenkins website

When I first started working on the Jenkins website, then called by a different name, I selected Drupal, an extensible content management system, to get the job done. Like Jenkins itself, Drupal is easy to set up, install plugins and authoring content is done in a web UI. For the past seven years Drupal has served us well, but it is time to move on to something better suited for our needs.

The general requirements for something newer were:

  1. Easy to edit and create content

  2. Changes to content should be tracked and reviewable

  3. Any Jenkins contributor should be able to participate

  4. Support mixed content types

The consensus was that a statically-generated site, with raw content hosted on GitHub, would meet the majority of the "ease-of-use" type requirements. The remainder could be addressed depending on the implementation. A couple of years ago I tried to rebuild the site with static content using Jekyll, commonly used by GitHub Pages, but the effort stalled as I ran into challenges with the mixture of content types we need to manage (stories, events, pages, people, etc).

Having recently discovered Awestruct, a more versatile and sophisticated static-site generator that powers sites like asciidoctor.org, I ventured down that path.

To make a long story short, over the holiday break I finally pulled the trigger and switched jenkins-ci.org over to the new site. In fact, the page you’re reading right now was authored and published via our new jenkins static site.

If you look at the bottom left-hand corner of this page there is a link titled "Improve this page" which will take you directly to GitHub to edit this post!

We have many more improvements to come for the Jenkins website, which are tracked in JIRA, but for now I invite members of the Jenkins community to help curate, correct and create new blog posts and pages for jenkins-ci.org!

Jenkins at SCaLE 14x

SCaLE 14x

For the past few years, a couple members of the Jenkins project have made the trip to Los Angeles for the Southern California Linux Expo. Despite the name it’s a fairly broad open source technology conference and since it is hosted prior to FOSDEM, it’s also a good conference to get us in the open source mood after the holiday break.

Unlike previous years, when SCaLE was hosted at the LAX Hilton, this year it has grown and moved to the Pasadena Convention Center. There, as with previous years, we’ll have a table in the expo hall with plenty of stickers and perhaps some other forms of swag available for devotees to collect.

The expo hall will be open January 23rd and January 24th, and a few Jenkins contributors will be there to ask questions to, talk about CI/CD and hand out stickers.

Additionally, I have a presentation on Saturday, January 23rd titled "Continuous Delivery of Infrastructure with Jenkins"

Talk abstract

In this talk we will review continuous delivery concepts and put them into practice by building a continuous delivery pipeline with Jenkins to test, stage and deploy to infrastructure code to production. Reducing the effort, error rate and time it takes to deploy a configuration to change to production means less time fighting fires and more time doing what you want.

During the talk I’ll be highlighting some of the positive, and negative, patterns used by the Jenkins infrastructure team to manage, test and deliver the Jenkins project’s own infrastructure. Sort of a followup from my 2014 PuppetConf talk about migrating Jenkins infrastructure from masterless Puppet to a Puppet Enterprise oriented installation.

If you’re in the LA area, we hope to see you for SCaLE 14X in Pasadena!

December JAM World Tour: Toulouse, France

On December 15, the Toulouse JAM was co-hosted with the Toulouse JUG and Toulouse DevOps. Indeed it made sense since Jenkins is written in Java, makes use of Groovy code in many places (system groovy script, job dsl, workflow…), and it also made sense to co-organize with the local DevOps community since Jenkins is also a great tool to enable Continuous Integration, Continuous Delivery and automation in general. There were 103 RSVPs, with 80 to 90 people in attendance.

There were 3 talks planned for the evening:

Photos can be found here