Psycopg Buildbot online
От | Daniele Varrazzo |
---|---|
Тема | Psycopg Buildbot online |
Дата | |
Msg-id | AANLkTimmpmkvXsQm1=V-dCsdQNvQ6eMkosUPFHs4A=hG@mail.gmail.com обсуждение исходный текст |
Список | psycopg |
Hello, 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 scripts. - 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. -- Daniele
В списке psycopg по дате отправления: