Recent Blog Posts

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.

Yesterday, Kohsuke announced that the 'jruby' branch of jenkins-core had been merged to master. This doesn’t mean that we’re done and that you can go forth and write pure ruby plugins…​ not by any stretch of the imagination. Instead, what it does mean, is that the Jenkins mainline is much more friendly to runtime analysis of classes with which it is not familiar. The problem When analyzing plugin classes, Jenkins uses just about every kind of metadata you can think of to get information about them: Class name, Field names, method names, member modifiers, annotations, you name it. It even uses the containing class relationship for inner classes to match Descriptors with what they describe. It’s all a great example of convention over configuration (CoC). In fact, I’ve never really seen CoC implemented in a Java project before as successfully as it has been in Jenkins. Plugin authors don’t have to duplicate any metadata that Jenkins can figure out for you — and it’s alot! The drawback though, is that extensions depend very heavily on conforming to the structure of a conventional Java class. The changes in this merge, and in several of the modules on which Jenkins depends, allow more than ever to get this information by asking an object directly rather than querying its private class structure. The Kicker Many of theses changes aren’t even JRuby specific! While they do enable JRuby integration, They’re really just making things more friendly for dynamic languages in general. So, in theory, it should pave the way for others like JavaScript and Python. Where now? We’re still working on the ruby runtime and tools which will provide as crisp a Ruby development experience as we can. I don’t want to proffer an estimate of when those will begin to be useable, but it is important to mark this very important milestone and explain what it does and does not mean. We need you! There is still much work to be done to enable a writing Jenkins plugins in Ruby, we are looking for people who know Ruby and feel like pitching in: writing Rake tasks, improving the glue layer, documentation, etc. If you’re interested, most of the action is happening on the jenkinsrb@googlegroups.com mailing list, so join us!

You know that the night is going to be productive whenever @kohsukekawa shows up, and last night was no exception. We talked about problems on the horizon, potential solutions, and then I spent the last half hour ripping a bit of code. The truth of the matter is that most of the changes that have to be done to Jenkins core have already been made, so now the bulk of the heavy lifting falls to the Ruby side of things (right now, me). Anyhow, on to the notes! Attendees @kohsukekawa, @cowboyd extract more stuff into the jenkins-plugins.rb support library (@cowboyd) We’re in the process of extracting, normalizing, documenting all the goop that’s currently residing in the ruby plugins playground into a formal plugin support gem called jenkins-plugins https://github.com/cowboyd/jenkins-plugins.rb recruit Rubyists to implement non-Jenkins specific code (@kohsukekawa) If you know Ruby and would like to be able to write Jenkins plugins with it, but don’t know the first thing about Jenkins and/or JRuby, that’s OK. You can help by implementing some of the cucumber features found in that repo @kohsukekawa is going to be knocking on your door to ask if you’re ready to step up, so I hope you’ve been nice this year! testing strategy (@cowboyd, @kohsukekawa) Ruby folk love their tests, and a plugin develompent solution won’t be complete unless testing is a breeze. That means that as we extract the plugin support library, we take make sure you can test plugin classes in isolation. On the Jenkins side, KK will think about how to run tests that require a full Jenkins environment. A system like this exists currently for testing java plugins, but some thought might be required on how to do this for Ruby. packaging reloaded (@kohsukekawa) KK is going to jump in and write some rake tasks to take a ruby plugin structure and package it into a valid .hpi file, and with no maven involved. According to him, Ruby plugins aren’t the only system that wants to run maven-free. There is desire to be able to do plugin development with Gradle (another Java build system), so this could be a double win. different schedule (@kohsukekawa) 8:30pm Central in North America, doesn’t seem to be a very good time. Especially for hackers in Asia Pacific. KK will investigate a new time that works for everybody and encourages more participation.

After a one week hiatus, we returned to the weekly hack session on a mission light up the sky with fire! Attendees Charles Lowell, Rasheed Abdul-Aziz, Hiroshi Nakamura Discussion/Accomplished How to manage the different ScriptingContainers inside the Jenkins renamed the experimental repo where we’ve been doing all of our development from fog.hpi to the more aptly name [ https://github.com/cowboyd/jenkins-ruby-plugins-playground ] started a separate gem for housing the support libraries for jenkins here [ https://github.com/cowboyd/jenkins-plugins.rb ] started with more formal definition of the plugin API there.