openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

On Thu, Feb 17, 2011 at 12:53 AM, Brian Schott <bfschott@xxxxxxxxx> 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