new scripts to drive nightly builds available, please try

[Volker Krause]

On Monday 03 May 2010 21:46:36 Alexander Neundorf wrote:
> On Monday 03 May 2010, Volker Krause wrote:
> > On Sunday 02 May 2010 14:26:56 Alexander Neundorf wrote:
> > > On Sunday 02 May 2010, Volker Krause wrote:
> > > > My Linux build still runs on a simple shell script, my Windows/mingw
> > > > build
> > >
> > > Can you post that script here ?
> > > I'd like to have a look at it.
> >
> > attached, but rather boring and relies heavily on macros in my .bashrc ;)
>
> No, not boring. Thanks :-)
>
> > > > [1] It would be nice if it would be possible to pass additional
> > > > arguments to ctest when using e.g. make Experimental in some way. In
> > > > our case we
> > >
> > > In which case do you need "make Experimental" ?
> > > This just builds what you currently have on your disk.
> >
> > I used make Experimental just as an example, I guess we eventually want
> > Continuous instead in this case. But since the goal is minimal-intrusive
> > integration into an existing system, it'll need some adjustments (such as
> > printing the full logs and not doing svn up for example).
>
> Why shouldn't it do svn up ?
>
> If I understand correctly how ctest and cdash work together, I think if
> ctest doesn't do this, then cdash is not able to send the notification
> emails (because it receives the update information via ctest).

right, that's how it works idealy in my understanding as well. But as I said 
the goal here is minimal intrusive integration of cdash reporting into an 
existing continous package building system. This already does a svn checkout 
of a specific version and thus would not want anything messing around with 
that. The build itself is driven by the usual Debian package building tools, 
which limits our possibilities of injecting ctest calls for that as well. 
Certainly not perfect, but IMHO just build results (no update and test) are 
still better than nothing, especially when run more or less continously on a 
clean system for two architectures :)

This of course does not replace "real" ctest builds, but it allows us to 
collect results of already existing automatic builds in a central place.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20100504/e8f9dd9d/attachment.sig