Good bye Java6

About two years ago, we bumped our runtime JRE requirement from Java5 to Java6. And so the time has come once again for us to finally move on to Java7. Because of all the new language features, many of us the developers really wanted to move right on to Java8, but after much discussion we settled to move to Java7 first and then to Java8.

So here is the plan:

  • Starting Jenkins 1.608, we start advertising that we will be moving on to Java7, which is why you are reading this.
  • Starting Jenkins 1.610 (2 weeks from now), we will ship so-called 51.0 class files that will only load on Java7+. This gives some more warnings to those who don't read our blog.
  • Unless we hear uproar from users, starting around 1.614 (6 weeks from now), core developers will start linking directly to new Java7 APIs.

Google Apps SSO no longer supported in Jenkins OpenID plugin

This is a guest post from Owen Mehegan (aka autojack)

In 2014 Google announced that they will be shutting down their OpenID 2.0 authentication endpoint and replacing it with Google+ Sign-in, a library built on top of OpenID Connect. The old Google endpoint will shut down on April 20th, 2015! Accordingly, if you are using the Jenkins OpenID plugin to authenticate users with the ‘Google Apps SSO’ feature (typically when Google hosts your personal or corporate email), you need to upgrade. Ryan Campbell took the initiative to develop the new Google Login plugin which implements the Google+ Sign-in functionality. This is the recommended solution going forward. Follow the steps here to configure it for your site. Note that you DON’T need to have a Google+ social network account/profile.

Workflow plugin is 1.0

Jenkins started with a notion of jobs and builds at heart. One script is one job, and as you repeatedly execute jobs, it creates builds as records. As the use case of Jenkins gets more sophisticated, people started combining jobs to orchestrate ever more complex activities.

A number of plugins have been developed to enable all sorts of different ways to compose jobs, and many are used quite successfully in production. But this resulted in a certain degree of complexity for users to figure out how to assemble these plugins.

So we felt the need to develop a single unified solution that subsumes all these different ways to orchestrate activities that may span across multiple build slaves, code repositories, etc. Various inputs from users as well as other plugin developers played a key role.

The result of this is the workflow plugin, which is what a number of us, including Jesse Glick an myself, are focused on in the past few months.

The plugin approaches the problem by defining a DSL for you to describe an execution of a job. Various convenient primitives are available, such as executing shell scripts, checking out the source code, obtaining an executor or a build workspace, etc.

Workflow plugin code walk-through

Jesse and I will walk through the source code of the workflow plugin, highlights key abstractions and extension points, and discuss how they are put together.

If you are interested in developing or retrofitting plugins to work with workflows, I think you'll find this session interesting.

The event will be on Google Hangout tomorrow. The time of the day is the same as usual office hours.

Official Jenkins LTS docker image

(This is a guest post from Michael Neale)

Recently at the Docker Conference (DockerCon) the Docker Hub was announced.

The hub (which includes their image building and storage service) also provides some "official" images (sometimes they call them repositories - they are really just sets of images).

So after talking with all sorts of people we decided to create an official Jenkins image - which is hosted by the docker hub simply as "jenkins".

So when you run "docker pull jenkins" - it will be grabbing this image. This is based on the current LTS (and will be kept up to date with the LTS) - but does not include the weekly releases (yet). Having a jenkins image that is fairly basic (it includes enough to run some basic builds, as well as jenkins itself) built on the LTS, on the latest LTS of Ubuntu seemed quite convenient - and easy to maintain using the official Ubuntu/Debian packaging of Jenkins.