Build Server web interface

[Alexander Neundorf]

On Sunday 11 October 2009, you wrote:
> Alexander Neundorf schrieb:
> > On Friday 09 October 2009, Patrick Spendrin wrote:
> >> Hi everybody,
> >>
> >> in the last days I have mostly been working on a webinterface for our
> >> build server: It currently resides under
> >> http://winkde.org/pub/kde/ports/win32/dashboard/ but might change
> >> location in the future if we have 64bit builds.
> >>
> >> I have outlined some features I have in mind already on my blog post:
> >> http://saroengels.blogspot.com/2009/10/build-server-web.html
> >>
> >> Especially the nightly builds will hopefully before monday.
> >>
> >> I hope it is of some use for you & this way we can improve KDE on
> >> Windows even more.
> >
> > Nice :-)
> > But why it it necessary to implement an own solution instead of trying to
> > use cdash ? Which features are missing or in what other way doesn't it
> > work as required for the Windows nightly builds ?
>
> We have a completely set up dependency chain.

This is emerge, right ?

> We can change anything we want in our code.
> CDash currently tries to take care of everything, beginning from
> fetching the sources up to running the unittests. 

There are two components, one is the web interface, cdash, the other one is 
the part which gets the sources, builds and runs the unit tests, this is 
ctest. When doing a Nightly/Continuous build with ctest, ctest submits some 
xml file to cdash at the end with the results.

This is the "core" of the ctest script I'm using for kdelibs, kdesupport and 
some others:

-----------8<--------------8<--------------8<------------------

ctest_empty_binary_directory("${CTEST_BINARY_DIRECTORY}")
ctest_start(Nightly)
ctest_update(SOURCE "${CTEST_SOURCE_DIRECTORY}" )

kde_ctest_write_initial_cache("${CTEST_BINARY_DIRECTORY}" 
                              CMAKE_INSTALL_PREFIX BUILD_experimental )
ctest_configure(BUILD "${CTEST_BINARY_DIRECTORY}" )
ctest_build(BUILD     "${CTEST_BINARY_DIRECTORY}" )
ctest_test(BUILD      "${CTEST_BINARY_DIRECTORY}" )
ctest_submit()

-----------8<--------------8<--------------8<------------------

So, each step is invoked explicitely, including the svn update/checkout via 
ctest_update(). I haven't tried what happens if this step is skipped, and you 
only leave the configure, build, test and submit steps in the script.
Maybe also the configure-step could be skipped if this is already done by 
emerge.
A disadvantage of leaving out the ctest_update() step would be that in case of 
breakage, the webinterface does not know which commits happened which may 
have introduced the breakage, and so it can't send emails to those 
committers.

> We already have this 
> code, we would have to either find a way to translate everything into
> CDash or rewrite it (this would be a lot of work). This seems to be less
> flexible for us, as with the currently solution we can use the same code
> for both automatic building of packages, as for building packages on
> each computer for each developer.

Alex