JenkinsCI

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.

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.

Hosting your Hudson plugin at Github

For as long as Hudson's had a plugin model and development community, we've provided source code and binary hosting through our Subversion repo at java.net. But what if you're a plugin developer and you don't want to use Subversion? Well, we have an alternative for your source code: host it with Hudson on GitHub.

Octocat!

To get this in place, send an email to dev@hudson.dev.java.net (or ask in the IRC channel) asking to get a repository created for your plugin at Github. Make sure to include the name of the plugin and your Github username (and the Github usernames of any other developers who'll be pushing to your plugin's repo). If your plugin is already in Github, include the URL for the existing repo so that we can fork it. One of the Hudson admins will create the repository (forking if appropriate) and add the user(s) to the list of users with push access to the Hudson-hosted repositories at Github. Once you hear back from them, you'll be able to push code to the new repository.

You will need to make a few changes to your plugin's POM, as compared to what works for a plugin POM in the java.net Subversion tree.

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.