[Boost-cmake] What we're doing testing-wise (was Status and future of boost-cmake)

From: troy d. straszheim (troy_at_[hidden])
Date: 2008-07-02 14:25:34

Miguel A. Figueroa-Villanueva wrote:
>>> - Is there a CDash dashboard actively running? It seems that the
>>> http://dart.resophonic.com/boost_1_34_0/Dashboard has been down for
>>> the last 4 days at least...
>> Troy's been working on an updated system that isn't based on CDash. I
>> haven't been keeping up with it as well as I should, but I expect
>> we'll see more cool stuff from him later on.
> 
> I'd like to know the details here... if it is ctest/CDash I can help
> to set these up and later in august I could probably setup a public
> dashboard (Now the network administrator that is in charge of the
> equipment is in vacation and I need him to resize the virtualized qemu
> image).
> 

I think what we're doing here is pretty compelling.   The working title 
is 'traash' (trac + dash).  We're *not* using ctest/cdash/dash or any of 
that.  See the archives for this list, there are some long threads there 
that explain the reasoning. See also 
tools/build/CMake/BoostTesting.cmake and 
tools/build/CMake/BoostBuildSlave.cmake, and the various python scripts 
that do the low-level work:  tools/build/CMake/*.py.in.  There are user 
docs at

   http://svn.boost.org/trac/boost/wiki/CMakeForRegressionTesters

and the 'dashboard'/trac plugin is at

   http://boost.resophonic.com/trac/traash

There is a 'build slave runner' script named run_continuous_slave.py
that is put into your build directory that runs incremental builds
similar to how 'ctest -D Continuous' does.   This business of setting up 
build slaves, continuous/nightly builds, configuration, etc, tends to be
brittle but needs to be solid as a metal desk... a lot of the users 
won't be experts.  Any development/testing/documenting that you might 
feel like doing here is most welcome.

The dashboardish trac plugin is slow (for various fixable reasons) and 
needs more features (it only has a couple of views), but it is easy to 
extend and I already find it useful.  I think it won't be long before we 
are more effective at communicating the current state of the release 
branch than the current testing system is, even with far fewer people 
and machines.   I expect this to be a big help making our case.

The long-term intention here is to factor out the client-side 
cmake/python infrastructure and post the trac plugin on trac-hacks, 
making this thing generally available to cmake/trac based projects.

-t