I've set up a buildbot system to perform integration tests on psycopg.
The more impressive page is probably the waterfall, currently showing
an all green situation: http://initd.org/buildbot/waterfall
Psycopg has now a quite complete test suite, containing about 300
tests. The problem is testing not only the developer's setup, but all
the supported python and postgres versions. The branch I've been
developing supports 6 Python versions (from 2.4 to 3.2) and 8
PostgreSQL versions (from 7.4 to 9.1). And I think it's not a case
that the last bugs reported have been mostly integration bugs: we have
released 2.3.1 because of a build problem on CentOS 5.5 64bit (ticket
#23) and 2.3.2 because of a problem with pgBouncer (ticket #24).
In the current buildbot setup, a slave creates the sdist package from
the git source (currently from the python3 branch of my git repos;
we'll switch it to the main repos as soon as everything is merged).
Several other slaves wait for a new tarball to be available: they
download, unpack, compile and test it. Currently there are two Ubuntu
test machines (32 and 64 bit) covering a complete test grid, plus
others for more specific setups. For "complete grid" I mean: each
slave compiles psycopg2 for the 6 supported python versions and tests
the result against the 8 supported postgres versions. Each test is
performed both in sync and async mode, for a total of 192 test suite
runs. In these tests the library is always compiled and linked with
libpq 9.0: global coverage of all the possible Py/libpq/PG
combinations I think is out of question (they would be 1536 runs and
we know that currently libpq < 9 doesn't work fine with postgres >=9
for the reasons explained yesterday). But we may add some sample runs
just to ensure the build doesn't break with older (or newer) libpq
versions, or if we decide to do something for the 9.0 bytea problem
ecc. I already have a CentOS VM too to check for problems such as
ticket #24, I just have to plug it back into the system.
Of course we have not finished yet!
- If you have some peculiar combination of software/hardware and you
want to ensure psycopg won't break against it (PostgreSQL 8.3.10 with
German dates against Python 2.5.1 on Slackware 31bits and a half
running on an array of Arduino...), you may provide a build slave that
will be called whenever new code is checked in.
- We have no test builds for Mac OS X, but a lot of OS X people
complaining that building is hard... I would like to have some OS X
slave in the system. Can anybody provide one?
- Ideally, buildbot will be used to build/test the window package too.
The buildbot has code to build and test the lib mingw, but it would be
nice to have the official package automatically built. Jason, tell me
when you are ready, and I can give you a hand to automatize your build
- Connection poolers still give pain: I think I'll need a chat with
pgBouncer guys to understand what is supposed to work and what is out
of question, then fix the test suite... and have yet more slaves.
If you want to collaborate providing your slave or improving the
tests, you can check out the buildmaster code from
<https://github.com/dvarrazzo/psycobuild>: the short version of the
instructions is: checkout the code, install buildbot, configure a
slave, create a patch with the configuration and send it us. More
details are in the project README.
Feedback, questions and collaboration are welcome. Regards.
psycopg by date
|Next:||From: W. Matthew Wilson||Date: 2011-01-19 20:06:53|
|Subject: How to use the postgresql money type?|
|Previous:||From: ganesh gajre||Date: 2011-01-18 13:24:43|
|Subject: Re: psycopg2 Operational Error|