Report bugs and win Kindle

CloudBees is running a 60-days "bring me bugs" contest for the Jenkins project where you may win a Kindle and Amazon gift cards for a bug report you made during the contest period. See the linked site for details about how to enter into the drawing. Greg Moy from Electronic Arts has already won for the first week, but there are more rounds to come.

Several years ago Sun did the same thing around GlassFish, and it was useful to drive more participations into the project. Whether or not you were around the last time, don't forget to participate this time.

IPS Packages of Jenkins for Solaris/OpenIndiana

Image Packaging System (IPS) is a new package manager Sun has developed for OpenSolaris. While I have my doubts about whether a brand-new package manager was a good way of spending engineering resources, OpenSolaris had a number of very nice features that made it a convincing platform to run Jenkins, thanks to SMF, ZFS, and zones. So I used to produce IPS packages for Jenkins. I lost the ability to do this as I left Oracle and lost access to a Solaris system, but a recent blog post renewed my interest.

So I'm happy to announce that the Jenkins project has started producing IPS packages for the releases. With this addition, the Jekins project now produces 9 packages on different platforms (10, if you count Ruby as a separate platform :-)

Jenkins Long-Term Release 1.409.2 is out

We just posted the updated Long-term Release (LTS) of 1.409.2.

Just as a recap, with LTS releases, we plan on providing a release train that only has backported changes. 1.409.2 contains a handful of important bug fixes since 1.409.1. For more about LTS, see this wiki page.

Thanks to the heroic effort of those who are involved, namely Vojtech Juranek and a bunch of heroes, this release went through a rather rigorous testing, including all the automated tests we have plus a considerable number of manual eye-ball tests.

To download, click the "Long-Term Support Release" tab from the top page. If you've already been using LTS, you should start receiving update notifications soon.

Call for Testers: Upcoming LTS update

A couple of months ago Jenkins embarked on an new project, the Jenkins "LTS" (Long Term Support) release line. A LTS branch of development is common in most major open source projects, especially those with substantial corporate adoption, so this was a great step for the project as a whole.

We're now coming up on the second LTS release, which will be an incremental update to the previous one (1.409.1) with only the most important fixes back-ported to the branch.

Now is when we need your help.

We need testers and interested parties from the community to help verify the stability of the planned LTS update, 1.409.2, which is now in the release candidate stages.

The testing of 1.409.2 has been spearheaded by community member vjuranek who has created this fantastic test matrix to help coordinate testing of release candidates.

The LTS project is entirely community driven, so your input is invaluable in making these releases successful.

If you're interested in helping, speak up on the -dev mailing list and start pitching in on the test matrix!

JRuby Branch merged!

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 mailing list, so join us!