Submitted by kohsuke on Mon, 2014-05-19 18:27
This week I'm going to do an office hour on how to write an acceptance test in Jenkins acceptance test harness. The event is on Wednesday 11am PT.
This new Selenium-based test harness is full of page objects and other abstractions that let you write blackbox integration tests on Jenkins and its plugins, as well as how they behave under various environments.
Unlike our regular office hours, the event is done through Hangout on air. But I do want at least several people to join Hangout interactively, not just watch the event in a read-only mode.
To join the event interactively (as opposed to read-only), I think you need to come here (but since Hangout URL can change, please check back on this post right before the office hour begins, so that I can post an up-to-date URL.)
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.
[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.
And as they say, now you're cooking with gas!
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.