Build Server web interface

Patrick Spendrin ps_ml at gmx.de
Sun Oct 11 19:26:10 CEST 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexander Neundorf schrieb:
> 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.
Ok, I'll check this stuff, I don't know if we really want to disturb the
programmers already though ;-)
This seems like it would keep submissions open to e.g. only include
ctest_test too?! This way it would be rather easy to integrate for us
(Simply write a small script and off we go - even ctest_update could be
run before).
I will see if I can get ctest to work this way.
> 
>> 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
regards,
Patrick
> _______________________________________________
> Kde-windows mailing list
> Kde-windows at kde.org
> https://mail.kde.org/mailman/listinfo/kde-windows
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkrSFTIACgkQi49rfdk/G3ZdfgCgnDmogcQrzEmBIy8K42WkIuxh
PGIAn1BQxG6BxlBXUTQ9nnVQuv3rVUy6
=gfSY
-----END PGP SIGNATURE-----


More information about the Kde-windows mailing list