In São Paulo from this weekend

I’ll be flying to Sao Paulo this week to attend Jenkins meet-up (Saturday) and JavaOne Latin America (next Tuesday and onward).

The last time I visited Brazil was a few years ago, but thanks to Mauricio Leal, whom I tagged around with for a JUG tour around Brazil, it was really a blast. This time around I don’t have the benefit of the local guy to the degree I had before, but I’m really looking forward to it.

The major pre-travel issue was that the Brazilian government run out of the visa stickers. But I made it just in time (or more precisely I hopefully will be — I’ll be picking up my passport Wednesday and flying Thursday. Phew!)

The highlight of the trip will be the first-eve Jenkins meet up in São Paulo — I’ve been a big fan of local communities where there exists a language barrier. I’m from Japan, so I’ve seen it the first hand the value of local communities would bring to the table. The speaker/session line up is amazing, the event is free, and there’ll be a social at the end, so if you are in the area and has been interested in meeting with fellow Jenkins developers and users, please RSVP.

But if you can’t come in person, at least please consider joinining the Brazilian Portaguese mailing list of Jenkins users, which we are launching.

I don’t really have any plans on Sunday and Monday — any sight-seeing suggestions and/or interest of meeting up and chatting about stuff would be more than welcome. Leave the comment here, or see the right for my e-mail address.

POTD: iOS device detection in Jenkins

I was talking to my colleague Mark Prichard about mobile development with Jenkins, and I came up with this idea.

If you are doing iOS app testing with real devices, you need to tether the device with a computer so that you can push the app-to-be-tested to the device. In a local development environment, you’d naturally do this by hooking up a device to your laptop.

But in the CI environment, we can do better. Imagine if you have a Jenkins master connected to a dozen Mac minis, where each Mac mini is then connected to various iOS devices. There’s nothing stopping Jenkins from listing up all the devices connected to all the slaves. Then based on this information, Jenkins can lease devices to builds.

Say someone wants to run a test somewhere. Jenkins can find an unused device and push it, then inject the coordinate of that device to the build. Or how about the axis in a matrix project that allows you to say “I need this test to run with iPhone 3GS,4,5 and iPad 2,3″ then Jenkins will run 5 runs of the tests in parallel?

To that end, as a post-JavaOne fun project, I developed a plugin that lists up all the iOS devices connected to Jenkins.

And just to show that we can list up various properties of this device:

I should be able to combine this with something like fruitstrap so that you can deploy apps from anywhere to any device connected to your Jenkins build farm.

What do you think? Shouldn’t this be interesting? Any thoughts?

The Butler’s Service: Promotion for Jenkins User Conference in Paris

We have just increased our enrollment capacity for the Jenkins User Conference (JUC) Paris, to be held on April 17th. The enthusiastic response to our first-ever Paris JUC has been terrific – and we want to get everyone there! The learning, networking and connecting that occurs within the Jenkins community at JUC is great to see. I saw it in spades last fall in San Francisco and it was terrific. I want every Jenkins user who is able to experience JUC to do so.

Since Mr. Jenkins, our iconic butler, and I are traveling to every JUC conference this year – all six of them – we have worked up a little scheme, with the folks from our sponsor CloudBees, to get YOU there, too.

Here is the deal. Jenkins and I are offering a special Butler’s Service promotion for JUC Paris. Ticket prices recently increased to the full conference price of €206, from a previously discounted rate of €104. The registration fee is needed to cover the cost of the conference, but we realize this can get in the way of people trying to attend. As a compromise, on this Thursday and Friday, 5-6 April, we will reduce the ticket price to the lower advance registration special pricing that was in effect. So on Thursday and Friday, you can still register for JUC Paris at the lower €104 price. (For anyone who paid the full conference price, we will refund the difference.)

Let Your Friends and Colleagues Know About This Special Offer!

To experience what JUC is like, watch the highlights video from our San Francisco conference. It will give you a feel for the quality of our speakers, the learning – and, yes, the fun that went on!

We have a lot to share with you on April 17. In addition to all of the great sessions we are offering, you’ll get to see many developers of the plugins you’ve been using (some of whom even I haven’t met before in person!), and there will be some exciting updates and other news to share about our favorite continuous integration platform. You will want to be there to hear and see it all, first hand.

I hope to see you on April 17 in Paris – be sure to sign up by end-of-day, Friday, and take advantage of this great deal served up by the Butler!

Come join us on “Selenium, Jenkins, Robots, Oh My!” tomorrow

I’ll be speaking tomorrow at San Francisco Selenium Meetup about Jenkins & Selenium — mainly recent improvements in the Selenium plugin, as well as several other new plugins relevant in the combination of Jenkins and Selenium, complete with a demo. I’ve got a couple of pet-peeves against the Selenium project, so I’m going to pitch them there to see the reaction, too.

I’ve told that Jason Huggins from Sauce Lab is going to pick up where he left off in the last Jenkins User Conference to talk about his robot, and Theo Cincotta from Eventbrite will give the case study of how Eventbrite uses Jenkins & Selenium together internally, so the whole thing should be a great mix of fun & useful topics, all packed in a Wednesday night from 6:30pm to 8:00pm, with beer and food.

The event is free, but you do need to RSVP, instead of the usual RSVP in the SF Selenium meetup group page at (which currently says 209 people coming, when the EventBrite RSVP page says the capacity is 100 people — so I need to check with the organizers to make sure they know what they are expecting…)

Writing programs that drive Jenkins

One of the interesting discussions during SCALE 10x was about using Jenkins as a piece of a bigger software. This person was interested in using Jenkins to run some business analysis operations, and wanted to have a separate interface for business oriented people. This is actually an emerging but common theme I hear from many users. Another company in San Jose actually built the workflow engine that uses Jenkins as a piece in a bigger application (aside from the actual build and test, this workflow involves reviews, approvals, etc.), and GitHub Janky can be classified as one such app, too.

This is something I always believed in — that every piece of software needs to be usable by a layer above. Or put another way, every software should be usable as a library.

So in this post I’m going to discuss various ways you can programmatically drive Jenkins.

Let’s start with the REST API of Jenkins. For most of the data Jenkins renders as HTML, you can access its XML version and JSON version (as well as a few other formats, like Python literal fragment.) You do this by adding /api to the page (see for example.) Those pages discusss other REST API where applicable. For example, you can POST to certain URL and it’ll create/update job definitions, etc.

If you are going to use REST API, you might find the auto-discovery for Jenkins useful. You can discover Jenkins on the local subnet via UDP broadcast, or DNS multi-cast. There’s also a distinctive HTTP header “Jenkins-Version” on the top page of Jenkins that allows your application to verify that it’s talking to a real Jenkins server, as well as an instance ID that allows you to identify Jenkins instanecs. These features allow you to build smarter applications.

For Jenkins protected by some authentication mechanism, you can use the user name + API key in the HTTP basic auth (and I want to add OAuth support here.)

REST API is great that it’s programming language agnostic. It is also convenient that neither the server nor the client has to trust each other. But those APIs are bound by the request/response oriented nature of the HTTP protocol.

Another great integration point for Jenkins is the CLI. This uses the same underlying technology that drives master/slave architecture, which enables your command line clients to be a lot more intelligent. For example, REST API exposes an URL that you can post to get a build started. But the equivalent command in CLI can have you block until the build is complete (and exit code indicates the status), or run the polling first and proceed to build only when the polling detects a change, or allow you perform a parameterized build with multiple file uploads very easily. For protected Jenkins, CLI supports SSH public key authentication to securely authenticate the client.

A slightly different version of the CLI is “Jenkins as SSH server”. Jenkins speaks the server side of the SSH protocol, and allow regular SSH clients to execute a subset of CLI commands. In this way, you don’t need any Java runtime installed on the client side to drive Jenkins.

These two integration APIs are often much easier to script than REST API.

Those APIs are available for non-privileged users, and they are great for small scale integrations. But for more sophisticated integration needs, we have additional APIs.

One is the REST API access to the Groovy console, which allows administrator users to run arbitrary Groovy script inside the Jenkins master JVM (and you can submit this script as POST payload, and get the response back as the HTTP response.) This allows you to tap into all the Jenkins object models. Unlike the REST API, in this way you can ship the computation, so in one round-trip you can do a lot. You can do the same with CLI, which also lets you access stdin/stdout of the CLI.

The other sophisticated integration API I wanted to talk about is the remoting API that does Java RPC (not to be confused with the remote API, which is the synonym for the REST API.) The remoting API is the underlying protocol that we use for master/slave communications, and it revolves around the notion of shipping a closure (and code associated with it) from one JVM to another, execute it, and get the result back. If your application runs elsewhere, you can establish the remoting API channel with Jenkins master, then prepare a Callable object. You can then have Jenkins master execute this closure, and the result is sent back to your JVM.

There’s an example of this available. You bootstrap this in the same way the CLI client talks to the master, then you “upgrade” the communication channel by activating the remote code download support (which requires the administrator privilege, for obvious reasons.)

The great thing about this is that your data structure is rich Java object model all the way, and you never have to translate your data to externalizable serialization data format like XML or JSON. This greatly simplifies your program.

I think this list covers all the major integration APIs that Jenkins offers. If you are building any interesting applications that uses Jenkins as a building block, please share your experience so that we can make it better!

Upcoming San Francisco training

CloudBees will be hosting another training in San Francisco Bay Area in January 26, 2012, and Feburary 23rd in Tokyo.

This 1-day training starts with the basics and then covers some of the advanced techniques, especially in combination with some plugins. As we deliver this training more, we gradually adjusted the material to cover more advanced topics, like promotion, build pipeline, parameterized triggers, and so on — the kind that’s getting more traction lately as Jenkins starts to encompass continuous delivery.

And for me, this training will be the first to use the latest “install plugins without restart” feature, so that should help with attendees keeping the focus a bit.

In these trainings, we cap the number of attendees to a fairly small size so that I can pay attention to each attendees enough. People normally bring in questions that go beyond the training curriculam to discuss the problems they face in their day-to-day Jenkins administrations. I welcome those, too!

If you are interested, please sign up while the seats are available!

Webinar: Jenkins Enterprise by CloudBees

On Janurary 10th, I’ll be doing a webinar about Jenkins Enterprise by CloudBees (formerly known as Nectar, which we renamed with the permission of the community.)

Jenkins Enterprise is Jenkins LTS + a number of CloudBees’ value-add plugins that help large and serious users, with the support. This release contains a number of new plugins, most notably the template plugin, which allows people to manage a large number of similar jobs, creating more domain friendly configuration mechanism, as well as means for the administrators to force certain practice on jobs.

The release also includes improvements to existing plugins — folders can now have views defined within them, and with VMWare, you can now tell Jenkins to use all computers in a specific folder, as opposed to configure individual machines one by one. There’s also a new job scheduling mode that makes Jenkins prefer idle slaves over partially used slaves that already have your workspace. And so on.

This release also lets you run these value-add plugins on top of non-LTS stock Jenkins.

All things combined, I think we got something interesting for many Jenkins users. Hope you can join us in this webinar.

Polling must die: triggering Jenkins builds from a git hook

As I keep saying, polling a repository from Jenkins is inefficient; it adds delay on the order of minutes before a build starts after a commit is pushed, and it adds additional loads. It is much better instead to do push-notification from the repository. In this post, I’m going to explain how to do this for Git, which brings this on par with Subversion.

The previous best practice of doing this is best summarized in this blog post. While this works, this is less than ideal. A part of the problem is that this requires hard coding of job names inside the repository hooks, making it hard to keep them up-to-date. Another problem is that if your job only cares about one branch in a busy repository, you don’t want a new build to be triggered. Finally, the last problem is that you need some extra work for secured Jenkins.

With the latest Git plugin 1.1.14 (that I just release now), you can now do this more easily by simply executing the following command:

curl http://yourserver/jenkins/git/notifyCommit?url=<URL of the Git repository>

This will scan all the jobs that’s configured to check out the specified URL, and if they are also configured with polling, it’ll immediately trigger the polling (and if that finds a change worth a build, a build will be triggered in turn.) This allows a script to remain the same when jobs come and go in Jenkins. Or if you have multiple repositories under a single repository host application (such as Gitosis), you can share a single post-receive hook script with all the repositories. Finally, this URL doesn’t require authentication even for secured Jenkins, because the server doesn’t directly use anything that the client is sending. It runs polling to verify that there is a change, before it actually starts a build.

One more final note — in Git, unlike Subversion, a repository does not have its own identity, and a single repository sometimes have multiple URLs to access it. In such a case, simply execute the curl commands multiple times with all the different URLs.

That’s it. I hope this will help reduce the use of polling and have more people switch to push notifications. It really is addictive to see the build start in a split second after you push a change.

Introducing template plugin

The Nectar 11.10 release that we just made has the template plugin, which I think is one of the very useful plugins that we added to Nectar that’s not available in open-source Jenkins. So I wanted to talk about it a bit.

Many serious Jenkins users have had this common problem that they’ve got a lot of jobs that look similar. JENKINS-3157, which is currently the most voted issue in JIRA, speaks to that same pain point. The template plugin is my answer to this problem.

What this plugin does, is to allow you to define a “model”. A model is an abstract concept that fits your particular problem domain. You do this through defining a set of attributes, kind of like how you define a class with a set of properties in Java, or how you define a table with a set of columns in database. You then define a transformation, which converts this model into something that Jenkins understands.

Creating a template

This is all rather abstract, so let’s look at a concrete example. We are going to define a hello world builder template, which lets you enforce the standard way to greet someone. You can then use this template to greet a lot of people in many jobs.

Installing this plugin, you get the “templates” menu on the left. You can click that and create a template:

You create a builder template from the same faimilar wizard you use to create a job:

Then here is the main meat.

There are two main things to configure here: attributes and a transformer.

When you define a template, you first ask yourself “what do I want my users to enter when they use my template?” The answer to that question becomes attributes. In this hello world builder, we want the user to configure who we are saying hello to, so we define one attribute named “target” for this purpose. The user should see the single text field for this, so we choose the type accordingly. The display name and inline help are self-explanatory. They control what the user will see when they are editing their free-style projects to use our new builder.

The second question you should ask when you define a template is “how does it execute?” (or more generally “how does it map to the terms Jenkins understands?”) The answer to that question becomes the transformer. In this tutorial, our builder will turn into a shell script that says hello (whereas your real template would probably turns into a shell script that gets some real work done, like building a component, running a test, etc.) So we’ll choose “generate a shell script to execute via Groovy”.

In the text area, we’ll fill the shell script that this build step is going to execute, but with expressions here and there of the form ${...} (because this is a Groovy template). ${target} refers to the actual value of the target attribute we defined above, and ${build.fullDisplayName} is a Groovy expression to access the getFullDisplayName() method (which returns the full name of the build) of the build object, which refers to the current build in progress. The ${build.fullDisplayName} needs to be quoted because this is going to look like test #1, and # gets interpreted by shell as a comment sign unless you quote it.

Using a template

Now that we have our first builder template, let’s create a free-style project that actually uses it. Go back to the Jenkins top page, and create a new free-style project. You’ll be taken to the configuration page. This part of Jenkins should be already familiar to you.

When you click “add build step”, you should see the newly created “Say Hello World” builder. You click it, and you see the say hello world builder added to your project. And you see the “target” attribute you defined in the configuration page.

I configured this to say hello to Kohsuke. If we save it and run it, lo and behold, you’ll see that it works.

[workspace] $ /bin/sh -xe /tmp/
+ echo Hello to Kohsuke from test #1
Hello to Kohsuke from test #1
Finished: SUCCESS

This allows you as the build guy to create and enfroce a certain way your stuff gets built/tested, and your users get shielded from all the gory details of how the build/test actually get done. You can create a layer between Jenkins and your users, and make Jenkins talk in the language your users understand, instead of making them talk in the language Jenkins understands. This is one of the points of the template plugin.

Changing a template

Now, let’s change the definition of the template, and see how it affects the instances.

We’ll go back to the template definition by going back to the top page, clicking the “Templates” link in the left, and clicking the configuration icon on the right to the “Say Hello World” template.

Instead of saying hello, now we make it say good evening.Click “save” to save this new definition:

Now, when you update the template definition, all the use of this template automatically reflects the change you made. So without revisiting the configuration page of the freestyle job, let’s simply schedule another build and see its console output:

[workspace] $ /bin/sh -xe /tmp/
+ echo Good evening to Kohsuke from test #2
Good evening to Kohsuke from test #2
Finished: SUCCESS

This is another point of the template plugin — when you change the definition, all the uses of this template get updated right away. So if you need to tweak how those high-level abstract concepts map to the lower level command sequences, you only need to edit it once and save it.

Try it out for yourself

If you like what you’ve read so far (I hope you do), please play with this. You can either download the whole Nectar and play it in a separate sandbox, or you can enable the secondary update center to install these plugins on your OSS Jenkins deployments.

And there’s a lot more to the template plugin, which I hope to write about in a few days.

Jenkins Community Survey

There’s currently a survey running to get a better sense of our use base. Those inputs help us steer the effort wisely, so we appreciate your taking time to fill it in. The result would be more useful if larger number of people participate, so feel free to encourage others to fill it in as well.

(The interesting thing about an open-source project is that you don’t get to tell other people what to work on — you can only try to influence them, and data like this is very useful.)

In the same spirit of the fundraising drive in NPR, CloudBees is throwing in a “thank you gift” of AppleTV as an added incentive. See their blog post for more details.