Recent Blog Posts

Updated usage statistics are now available at https://jenkins-ci.org/census This data has been scrubbed of distinguishing information as much as possible, filtered for installations we’ve seen at least twice a month with at least one job set up, and split up into monthly JSON files. Starting with August, we only have data on installations of version 1.368 or later - before that, reports go to the old Oracle-owned server, and we aren’t able to retrieve them. So that’s why you’ll see a fairly hefty drop in install count, etc from July to August. I haven’t had a chance to do any analysis to speak of on the data. I intend to get the plugin usage spreadsheet updated n the next few days, but I wanted to make this data available to you all ASAP. If you come up with any interesting analysis or use of the data, please let us know!

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, agent 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. If you’d like access to the data, please send an email to dev@hudson.dev.java.net or jump onto the IRC channel and ask - we’ll send you the URL and a private username/password which you’ll need to access the info. We’re also planning to do more analysis of the data ourselves, for now feast your eyes on this spreadsheet, which shows the total number of unique installations seen per month and the number of unique installations of each publicly available plugin per month.

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. 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. First, add the following to the ++ section: org.apache.maven.plugins maven-release-plugin 2.0 org.apache.maven.scm maven-scm-provider-gitexe 1.3 This is needed to make sure we’re overriding the parent POM’s SCM provider settings. Next, add the following to the ++ section: org.jvnet.wagon-svn wagon-svn 1.9 This is needed because we’re still going to be using wagon-svn to deploy the artifacts in the release process. Lastly, add an ` section, within the ` section of the POM, like the following: scm:git:git://github.com/hudson/your-plugin-repo.git scm:git:git@github.com:hudson/your-plugin-repo.git https://github.com/hudson/your-plugin-repo As with the first section, this is needed to override the default SCM settings in the parent POM. Make sure to change "your-plugin-repo" to your actual plugin repository name, of course! It’d also be a good idea to put a link to your Github repo on your plugin’s wiki page at the Hudson wiki, since the default source link will go to Subversion. Now, with these changes in place, committed and pushed to the master branch in your plugin’s repository, you should be able to run "mvn release:prepare release:perform" just as you would if the plugin were hosted in Subversion, with your plugin showing up in the Update Center within a few hours. Be sure that you’ve configured the login information for the java.net Maven repository, as detailed here - this is still needed for plugins hosted at and released from Github, since Hudson’s Maven repository still lives at java.net. If you run into any issues releasing your plugin from Github, first be sure to review the wiki page on plugin hosting, which addresses many of the issues you may encounter when running the Maven release plugin. If you’re still stumped, feel free to email the Hudson developer list or ask in the IRC channel for help.

In my capacity as Build Guy at Digg, I’ve written up a blog post on our new continuous deployment/code review/pre-tested commit workflow. We’re using a combination of Hudson, Git and Gerrit, Selenium and more to make sure that every change going to Digg’s new site has been thoroughly tested. Read the whole post, with all the juicy details over on Digg’s Technology Blog!

Hudson, like all web applications, is not immune from vulnerabilities that could open up attack vectors for malicious use. What puts Hudson in a league of its own compared to others is its ability to execute arbitrary commands on agent machines, or in the case of the EC2 plugin, execute arbitrary commands "in the cloud." In light of all this, Hudson is quite secure and offers a variety of mechanisms to reduce the potential for exploits. Despite Hudson’s security track record, you’ve managed to find a vulnerability in Hudson, and decide to don your white hat and inform the Hudson team. First off, let me commend you on your brilliant decision to report the vulnerability, you are truly a leader among men. Generally immediate public disclosure of vulnerabilities is frowned upon as it doesn’t give us much time to react, investigate and patch the hole. For this reason there is the " SECURITY" project in Hudson’s JIRA. The SECURITY project is a more locked down section of JIRA than the other projects and allows you to submit issues and have them reviewed by the Hudson core developers who can assess the vulnerability. When reporting the issue, it will be helpful to include information regarding the environment the Hudson instance is running in (such as the servlet container) as well as any pertinent reproduction steps so the team can reproduce, fix and verify with as little wheel-spinning as possible. What happens next wholly determines on the severity of the issue, if it’s a highly critical vulnerability, the team will likely make an out-of-schedule release and advise users to upgrade. If it’s a less critical hole, the fix will be included in an upcoming scheduled release. Either way, the Hudson team has a good track record of correct potential security holes in a timely fashion. After the hole you’ve discovered has been patched and released, you can revel in the fact that you helped make Hudson better, thanks! Image courtesy of ThinkGeek