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.
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.
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.
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.