Core

GeSHi library error: sites/default/modules/geshifilter/geshi is not a directory.

Hudson Anonymous Usage Data

In late 2008, the Hudson team released version 1.264 which added an anonymous reporting feature (you can opt-out in the "Manage Hudson" screen). The reporting feature has been sending information back to the Hudson team to help us understand how Hudson is used in aggregate; the info being reported includes the number of jobs configured, slave configurations, what plugins (and what versions of those plugins) are installed, and more. This data has not been available publicly until now! The raw data needed to be decrypted and scrubbed of any potentially identifying information, such as non-public plugin names or usernames in snapshot versions. We've finally scrubbed the data and are making it available!

The data is currently in monthly JSON bundles, organized by unique install key. We've filtered out reports of installations without any jobs configured, as well as any installations with only one report in a given month.

Quiet Period Feature

Commits often come in a burst. This seems to happen mainly for two reasons --- people sometimes forget to commit some files, and in the tranquility of waiting for your SCM to finish a commit, people sometimes realize the problems in the commit and they quickly make follow-up changes. The conventional wisdom is that the CI server should wait for the burst to finish before attempting a build. This is said to reduce the chance of having broken build, and it is also sometimes useful in reducing the average turn-around time for builds that take longer.

As such, Hudson is capable of waiting for a commit burst to be over before it triggers a new build, and this feature is called "quiet period." There are two parts in Hudson that interacts with the quiet period. One is the SCM polling behavior and the other is the queue.

The queue portion of the quiet period is straight-forward. When a build is scheduled into the queue with quiet period, the build will sit in the queue until the quiet period expires. If during this period, additional attempts are made to put the same build in the queue, the quiet period resets to its initial value. For example, if the quiet period is 5 minutes, and the build is put into the queue 9:00am and 9:03am, the actual build will only happen after 9:08am.

Big Security Fix! Hudson 1.371 Released

Hot on the heels of Hudson 1.370, which was released last Friday, the Hudson team released 1.371 which addresses a critical vulnerability in all Hudson versions prior to 1.371. The vulnerability was disclosed by InfraDNA in the following security advisory, which details the issue:

This critical vulnerability allows an attacker to use CLI commands that they are otherwise unauthorized for. CLI commands can perform various administrative operations.

It is advised that all Hudson instances be upgraded immediately to avoid data loss or other ill effects from this issue. If you're upgrading from a version earlier than 1.370, you can consult the changelog for details on the other bug fixes and enhancements covered by the upgrade of your version to 1.371.

If you run a Hudson instance, it is recommended that Hudson system admins subscribe to either the security advisories RSS feed or the advisories@ mailing list

Dogfooding Hudson - We're Looking for Slaves!

As you may have noticed, thanks to the link on this and the other pages here at hudson-labs.org, the Hudson development community has recently introduced ci.hudson-labs.org, the official Hudson-on-Hudson instance. We're currently building Hudson proper, the Hudson core RC branch, individual builds for the various Hudson plugins and Gerrit, as well as various libraries and infrastructure jobs Hudson depends on.

Hudson 1.368 Released!

Regular readers will recognize that I've been slacking off quite a bit lately with my release announcements, my apologies. With the release of 1.368 on Sunday, which fixed a few fairly important bugs, I figured I'd dusty off my blogging fedora and give this a shot.

This release has three bug fixes in it which were causing some issues for some users, particularly those deploying Hudson inside the recently released Tomcat 7.0 (see issue 6738).

Hudson users utilizing the JDK auto-installation feature between different platforms may have been affected by issue 6880 which was also fixed in this release.

Bringing up the rear is the fix to issue 7004 which detailed a few discrepencies between the /buildWithParameters and the /build remote APIs.

If you're not affected by these issues, you may want to wait for the soon-to-be-released 1.369 which has even more juicy bug fixes in it (with a dash of enhancements) to upgrade.