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
_______________________________________________
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
