Continuous integration for Python with Hudson

Thursday 5 November 2009 — This is nearly 15 years old. Be careful.

Continuous integration is a great idea: you configure a server to periodically pull your source code, build it, run the tests, run lint, measure coverage, and so on. Then it graphs everything, stores the results for examination, and so on.

I’d been trying to figure out how to use the Hudson CI server with Python, and the few times I tried to get my mind around it, it just wasn’t clicking. I happened to mention my mental block to Joe Heck, and a few days later, he produced Setting up a Python CI server with Hudson. It’s a great step-by-step how-to covering everything you need to get Hudson going for a Python project.

Running through his guide finally cleared the last misconception for me: continuous integration isn’t a build tool or a test runner. You don’t run Hudson on your development machine. Sounds silly, but something needed to clear it up, and this was it.

Thanks, Joe!

Comments

[gravatar]
Joe 9:19 PM on 5 Nov 2009
You're way welcome! Thanks for making coverage - because I'm taking advantage of it! Oh - and actually I do run hudson on my desktop. :-) at least when I'm doing project work at home. Just easier than running a VM all the time, especially when firing it up is "java -jar hudson.war"
[gravatar]
Ben 3:41 AM on 6 Nov 2009
Hi Ned,

I've been using hudson for a little while and I've actually patched the nose coverage plugin to give it an option called --cover-xml that gives you the cobertura coverage Joe mentions as part of the test run.

I had to do it this way as my test runner isn't a python module but a buildout produced script.

So my hudson build step lools like
./bin/test-runner-name --with-xunit --with-coverage --cover-package=package_1 --cover-xml
This is pretty nice as you only get what you're interested in looking at in the coverage report.

Would you like the diff?

Ben
[gravatar]
Ned Batchelder 8:28 AM on 7 Nov 2009
@Joe, I guess what I meant about dev machines was less about machines than it was about working trees. Trying to run Hudson against my actual working tree was a mistake, it's not the way Hudson was designed to run. It's much more keeping with the grain of the wood to point Hudson at the repo and have it pull its own sources. That's the step I was getting tangled up with.

Add a comment:

Ignore this:
Leave this empty:
Name is required. Either email or web are required. Email won't be displayed and I won't spam you. Your web site won't be indexed by search engines.
Don't put anything here:
Leave this empty:
Comment text is Markdown.