In SuRF we changed a lot of str() calls to unicode() which made code fail under Python 2.6.2. This wasn’t found through unit tests as my tests ran with the newest Python version only.
Luckily Hudson/Jenkins has a multi-configuration (or matrix) mode that runs a test with several configurations. This lets you for example run your tests on different Python versions to check for compatibility.
When creating a new job you just choose “Build multi-configuration project” and receive a configuration page mostly similar to a general project.
A bit further down the page there’s a special section called “Configuration matrix”. Here you can set several axes of parameters with multiple values. In the example shown I chose a variable python_version with values 2.5, 2.6 & 2.7. Additional I added a value for the Python distributed with Ubuntu so I make sure to catch newer versions as well as distribution specific issues.
As SuRF tests run against an RDF store tests should run sequentially (checked). Also to keep Jenkins from running all configurations if something fails I defined a “touchstone build”. Only if this build succeeds all the other options will be tried.
I had one issue when setting up a Git repository – the same error I reported before: “FATAL: Could not apply tag jenkins-python_version=DISTRIB”. Setting the appropriate Git options did not work as explained in the simple set-up, and setting a default in Jenkin’s settings did not help either. I could only get the test to start by checking “Skip internal tag” which shows up when you click on “Advanced…” in section “Source code management”.
I now have two axes set-up for SuRF (one axis for different versions of rdflib), totally 16 distinct configurations which still complete pretty fast.
Setting up different Python versions
Here’s a short log on how I installed different Python versions in parallel on an Ubuntu system:
Install all build dependencies and get the Python source code
$ sudo aptitude build-dep python2.7
$ wget http://python.org/ftp/python/2.7.1/Python-2.7.1.tar.bz2
$ tar -xjf Python-2.7.1.tar.bz2
Now configure and install the version in parallel with others to a directory under Jenkins:
$ cd Python-2.7.1
$ ./configure –prefix=/home/jetty/jenkins/python
$ make altinstall
Probably repeat these steps for 2.5, 2.6 (and 3.2?).
2.5 2.6 2.7 DISTRIB
And now add a shell script before the actual test code:
rm -rf “.env”PIP_DOWNLOAD_CACHE=/home/jetty/jenkins/pip_download_cache pip install -E .env nose coverage
echo “**> creating virtualenv”
if [ “$python_version” = “DISTRIB” ] ; then
virtualenv -p /home/jetty/jenkins/python/bin/python$python_version .env
Now add a second shell script running the actual test. Use the virtualenv as e.g. described in my former post. Voila.