Posted by kohsuke
on August 19, 2006 at 9:36 PM PDT
The plugin support in Hudson is almost ready to ship. This shall let Hudson adapt to individual needs of different projects.
I've been spending some time on adding plugin support to Hudson .
What gradually became evident while developing Hudson was that every software development project has some different needs when it comes to their builds (just see how many plugins people have written for Maven , as an example.) So it's necessary for a CI system like Hudson to be able to adapt to these needs, and the obvious way to do that is by allowing plugins.
I have this exact problem at my work. Our QA folks use an in-house custom-built test harness to report test results. So naturally we wanted Hudson to take those reports and do the same test trend report that Hudson does for JUnit . But it didn't make sense to change Hudson to do this, because our group is the only one in the world that uses it. Our group also heavily uses Japex to keep track of performance. This framework reports performance test results in XML, and it has a capability to generate a nice trend report . Since those performance tests are triggered from Hudson, isn't it nice if Hudson can take advantage of this Japex trend report and integrate those reports into Hudson?
Plugging various reports into Hudson is always interesting, because it literally adds a new dimension to the report --- namely the time axis. Say, when you are using Ant JUnit reports , it just tells you what tests passed and what tests failed. But Hudson can tell you more. In case of test reports, it can tell you what new tests started failing. So you can correlate the changes to the source code and additional failures/fixes. This is what the additional dimension lets us do.
This time axis information is useful in many different reports. In case of Japex, obviously being able to learn the performance regression is very handy. Or say, if someone writes a FindBugs plugin to Hudson, then we can learn about new problems introduced in a new commit, so you don't have to go through false positives.
Furthermore, Hudson can do these things without requring any additional configuration, because it already has infrastructure to record results from multiple runs. On the other hand, if you try to do this by yourself, you'd have to add more to your automation scripts.
I've always wanted to do this, but until recently the limitations in the underlying technology prevented me from doing this (I've always been curious about the lack of this kind of pluggability in JavaEE --- doesn't any large application need it?) Now that I fixed that, plugins can really integrate seamlessly into Hudson. So much so that you can't tell the difference between built-in functions and plugin-provided functions.
I'm almost ready to ship the first wave of plugins. At my work, I've already deployed most of them. I just need a few more days of "beta testing" by my colleagues. I also need a bit of refactoring Hudson code, so that changes I'll make in the future won't render plugins built today useless. Meanwhile, if you are interested in writing Hudson plugins, take a look at documentations (see the "Developing on Hudson" section) or just drop us a note.
And there are more plugins to come. I just started working with Rama to write a plugin to support the TCK test report format. And I'm sure you have more ideas.