Tutorial

Adding diagrams to Wiki

Thanks to the kindness from Gliffy, we can now add diagrams to Wiki pages, in a way that enables collaborative edits.

See more info, including a sample diagram in a Wiki page.

Building a software diamond with Jenkins

[Editor's Note: This is a guest post from Jenkins community member Tom Rini]

Alternatively: How to make your parallel jobs kick one last job at the end

Many of us have had occasion to think: "I could make this project build quicker if I could just run parts in parallel and then one final job to wrap it up."

Well, good news! Jenkins is here to help! With the Join Plugin you can do just that. Over on the confluence page it’s got a number of examples and fancy flow charts. But the take-away is that if you can describe the flow, you can make it happen. But you’re saying "wait, I need to pass information around between the jobs."

We’ve got that one covered for you too with the Parameterized Trigger Plugin. And here’s the best part, these two can work together! With both plugins installed you can follow the steps listed in the Build Parameters section of the Join Plugin.

Click to enlarge

And as they say, now you're cooking with gas!

Recent label and matrix project improvement

Today, I’d highlight two recent improvements to the label and matrix projects.

When you have multiple slaves in your Hudson build farm, you can use labels to classify slaves by their capability/environment/architecture/etc. For example, your one slave might have “32bit” and “windows” label, while another one might have “linux”, “ubuntu”, and “64bit.” (with plugins like platform-labeler plugin, you can attach labels automatically, too.) Or if you do Selenium testing, you might add browser names as labels to indicate which slave has which browser available.

With such set up, you then specify that such and such jobs can be only run on such and such labels. For example, you might say your “test-foo” job requires the “windows” label, while your “compile-bar” job might require the “macos” label.

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.

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.