March 2010
After Hudson got some major publicity at PyCon Atlanta 2010 I haven't been as quick as I would have liked with Python-related posts and tutorials. I use Hudson to build and test a number of pure Python modules and C extensions across numerous Python versions (covering 2.4 - 3.1). For most beginners, or those simply looking to get started with Python on Hudson, starting with my job configurations is too much at once, so instead I wanted to start at the "beginning" so to speak.
The trouble with getting people started with Hudson, given how simple and visual it is to use, is that articles with sample configurations are not particularly useful; a screencast however is a good medium for visually walking somebody through Hudson. The screencast below (also on YouTube) is the first in a series of screencasts I'll be doing, not only for Python on Hudson, but for Hudson overall.
This week's release comes slightly later than usual and is mostly a clean-up of a few bugs. Due to a problem with the Kohsuke's GitHub mirror of Hudson's core, I can't mine the commits for interesting information as per usual so you'll just have to trust that Hudson 1.353 is chock full of good, wholesome bug fixes. If the problem persists next week, I'll find a better way to dig up information on particularly releases that doesn't depend on the GitHub mirror.
Bugs fixed
- Tagging a repository can result in NPE.
- Fix possible form submission error when using multiple combobox elements. (issue 6025)
- Better escaping of test case names in test results pages. (issue 5982)
- Make radio buttons work in repeatable content, such as a build step. (issue 5028)
- Fixed the handling of verifying that the POM path entered for Maven projects exists. (issue 4693)
Enhancements
- Added link to builds in buildTimeTrend (issue 3993)
You can go grab the latest .war file straight from hudson-ci.org or if you're using a native package, use your package manager to upgrade.
A few weeks ago I passed a job listing that I had found through one of my many Google Alerts for Hudson-related queries to Andrew (abayer), following up on one of those job listings Andrew recently signed an offer to join the nice folks over at Digg to be their resident "build guy." On its own I thought "great for Andrew!" and nothing more, then I saw this thread on reddit which poses the question:
Anyone here a build engineer, or part of the build team? Could you please share your experience?
It seems, to me at least, the notion of "release engineering" is making a come-back, particularly in the aging "Web 2.0" world where companies like Digg, Facebook, Reddit, Twitter, etc are anywhere from five to ten years old. As these companies have aged a couple of important things have happened, their code-base has aged increasing the possibility of bitrot, but they have also expanded in terms of headcount. Start-ups that might have once slighted larger corporations like Oracle, Cisco VMWare and IBM for their burdensome process and longer release schedules now find themselves ensnared with massive code bases, larger development teams and complicated deployments.
In addition to the nice fancy new community contributed translations, which you can help with by installing the 
The day of hackery is upon us! Today is Day One of the 
