On Thu, Feb 17, 2011 at 12:53 AM, Brian Schott <[email protected]> wrote: > One thing we saw in the list and experienced first hand is that your Hudson > server uses a pre-configured environment and ours pulls virtual env every > time. We had failures on trunk that yours missed because of new pip pulled > versions. > > A fresh run_tests.sh -f needs to work. It is the only guaranteed sanity test > everybody can replicate. It might pull upstream bugs, but better to be ahead > of that curve than behind.
Although Soren adequately explained why he thinks that running run_tests.sh on Hudson should *not* be against a pip/virtualenv setup, I would like to state that I think it would be a good idea to have Hudson do *both*. In other words, for each pre-merge into trunk, Hudson would run two things: * run_tests.sh -N * run_tests.sh -V -f The former would verify that the commit will not break an *existing* installation. The latter would verify that the commit will not break a *new* installation. I don't see why the two cannot be run for each commit into trunk. The run_tests.sh -V -f would, of course, take a lot longer than run_tests.sh -N because the virtualenv needs to be destroyed, recreated, and all dependencies in tools/pip-requires need to be downloaded and installed. However, I feel the run_tests.sh -V -f is an important test to run, as it would pick up issues that have bitten a lot of developers -- for instance, the recent "from migrate import versioning" bug... > We are now triggering on trunk commit emails and running Hudson on both trunk > and our hpc-trunk. We can forward to a list or autogenerate bug report > somehow. Can you open up an SSH port/user on your build box and install the Hudson agent on it so we can link it to hudson.openstack.org's build machines? -jay _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
