The last Jenkins office hour of the year hosts Robert Sandell and Tomas Westling, who will go over newly open-sourced metadata plugin from Sony Mobile Communications (more about this story on their website). This team from Sony Mobile has been known for several other popular plugins, including the Gerrit trigger plugin. And I think this latest batch of plugins will not disappoint!

As I understand, this plugin is a library plugin, which is primarily meant to be consumed by other plugins. With help of other plugins using this plugin, it can classify jobs and slaves by adding metadata tags to them. This in turn enables more intelligent scheduling, views, access control, and so on.

Until now, Jenkins plugins written in Java or Groovy could only be built with Maven, using the maven-hpi-plugin to generate a proper manifest and archive which Jenkins can consume. But starting now, you can also use Gradle!

See the wiki for information on how you can use Gradle and the new gradle-jpi-plugin to build, test and release your Java or Groovy Jenkins plugin.

It's not often that I get to use that much hyperbole in a Jenkins blog post, but I think in this case it's allowable. A journey that started over a year ago by Charles Lowell has reached a new level, thanks to lots of help from Kohsuke along with Hiroshi Nakamura and Jørgen Tjernø.

As of today, with Jenkins 1.438, you can now download and install Ruby plugins from the update center (the Path Ignore plugin being the first).

Words simply can't express what a monumental achievement this is for the Jenkins project, both from the technical perspective but also in terms of what this means for the future of the project.

According to the languages dashboard on GitHub, Ruby is over two times as popular as Java on the site. I do not intend to start a language popularity contest here, but if we pretend just for a minute that the GitHub ecosystem is all that exists. Can you then imagine how powerful it would be to engage and include a community of open source developers that would be two times the size of the current pool of contributors? That's tremendous potential!

Great! Where do I start?

For those that are curious, the first officially released Ruby plugin for Jenkins is Jørgen's pathignore-plugin which can be found in the update center. If you're looking for a reference project, this is currently the most up-to-date plugin.

There is also a wiki page covering Ruby plugin development, which might be a little out-of-date but covers most of the essentials.

Additionally you might find the jenkins-prototype-plugin an interesting resource as it is practically a kitchen sink of demo/test Ruby plugin code.

Currently only a few extension points (BuildStep, Publisher, BuildWrapper) are mapped in a Ruby-friendly manner. Don't let that scare you though! If you dig around in the jenkins-plugin-runtime you can see how the existing extension points are mapped from Java into Ruby, because Ruby plugins are running under JRuby, if you need to access some Java APIs, you can do so without too much trouble.

The Thank Yous

Great efforts like this one don't just happen without support, which is why I'd like to call out and thank The FrontSide for their wonderful support, helping to cover costs of WebEx for Office Hours and covering Charles' time while he worked with Kohsuke on the internal plumbing needed to make Ruby plugins possible within Jenkins core. If the name "The FrontSide" looks familiar to you, that might be because they also created and donated the Jenkins logo!

We should also thank Lookout, Inc (full disclosure: Lookout is my employer) and CloudBees for affording some employee time for Jørgen and Kohsuke respectively to work on the project.

[Editor's Note: This is a guest post from Jenkins community member Tom Rini]

Alternatively: How to make your parallel jobs kick one last job at the end

Many of us have had occasion to think: "I could make this project build quicker if I could just run parts in parallel and then one final job to wrap it up."

Well, good news! Jenkins is here to help! With the Join Plugin you can do just that. Over on the confluence page it’s got a number of examples and fancy flow charts. But the take-away is that if you can describe the flow, you can make it happen. But you’re saying "wait, I need to pass information around between the jobs."

We’ve got that one covered for you too with the Parameterized Trigger Plugin. And here’s the best part, these two can work together! With both plugins installed you can follow the steps listed in the Build Parameters section of the Join Plugin.

And as they say, now you're cooking with gas!

[Editor's Note: For the past few weeks Jenkins community member Charles Lowell has been working with Kohsuke on adding support for building plugins in Ruby. As part of this effort, Charles has been hosting weekly hack sessions via WebEx]

As always, last night's Ruby Plugins hack session was a pleasure. Below is a quick notation of what items were discussed and/or accomplished followed by next steps to be taken my those in attendance.

Discussion/Accomplished

• Ruby Plugin project structure and how to bundle into an .hpi file.
• Review of the new XSTREAM serialization method
• API for marking fields as transient
• What mods, if any, are required to get .hpl to work with Ruby plugin

Next Steps

Charles

• to research what can be shared between JRuby ScriptingContainers
• API for unmarshaling hooks on serialized ruby objects
• Change the name of the repo :)
• Document... something!

Kohsuke

• test more view functions
• add debug mode outside of hpi:run