Andi Vajda <va...@apache.org> wrote: > > On Mar 20, 2010, at 18:41, Bill Janssen <jans...@parc.com> wrote: > > > Andi, > > > > Do you run what's called these days a continuous integration server? > > We > > use Hudson to continuously test UpLib, and find it very handy. I > > presume > > the ASF has such a setup somewhere. Since you've already got a set of > > tests for pylucene, it would be simple to set up a server to run those > > tests every time you make a change. It's almost ridiculously easy to > > do with Hudson, once you've got the tests written. > > No, I don't. I know Lucene does, so it's possible. What problem would > this be solving in the context of PyLucene/JCC ? How can it be > achieved without creating extra work ?
Sorry, unsolicited advice. :-) And there's no problem I'm aware of, it's just a QA thing. I was just thinking that I always hate to make changes without testing it on all platforms, especially in code where there's a lot of "if sys.platform == ..." tests. This is a lot easier to do with some kind of buildbot setup. If you have the tests already written (as you have), and a Hudson installation available, with test slaves for the various platforms, it's remarkably easy. Takes only a small shell script to set up an all-platforms test which is triggered every time a change is made to the Subversion or CVS repository. Hudson checks out the code, and runs the shell script on it. In my case, I've already got UpLib tests, and build scripts for the three OS platforms I support, so my test script comes down to something like $ svn update $ [set up paths to pick a particular compiler/Java/Python combo] $ [pick and run platform-specific build script] $ UPLIBRC=`pwd`/tests/tests.uplibrc make test Bill
