[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-buildsystem
Subject:    Re: Summary from Buildsystem BoF at Desktop Summit
From:       Volker Krause <vkrause () kde ! org>
Date:       2011-08-18 7:26:39
Message-ID: 3452415.8bsFuC2yn7 () vkpc9
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 17 August 2011 10:59:53 Torgny Nyblom wrote:
> On Wed, 17 Aug 2011 09:21:33 +0200, Volker Krause wrote:
> > On Monday 15 August 2011 23:31:26 Alexander Neundorf wrote:
> >> -----------------------------------------
> >> 8) Testing
> >> -----------------------------------------
> 
> [...]
> 
> > ok, so let me explain what I have been working on there.
> > 
> > The idea we came up with in Randa basically is to deploy more or less
> > blank
> > Linux VMs in a SETI@Home-style to as many as possible machines. They
> > continuously run kdesrc-build with enabled CDash reporting
> 
> [...]
> 
> > This approach addresses one specific problem of the entire CI topic,
> > namely
> > testing as many as possible of the various different build options we
> > have
> > (platform profiles, debug vs. release, different dependency versions,
> > with or
> > without optional dependencies, etc). This does not address testing on
> > different OS/platforms etc., so it's only one piece in the puzzle,
> > not the
> > single solution.
> 
> This sounds like it should be done regardless of the continuous
> integration builds.
> As it relies on community / volunteer provided resources on a not known
> time basis (or?).

Right, this is an extension of a traditional continuous build, definitely not 
a replacement. Since it entirely relies on community resources, it's using a 
stochastic approach by randomizing the build configuration, so the result will 
be approximately the same no matter if a specific VM is active or not.

> And there doesn't seem to a trigger to start testing when a change has
> been made as with the more traditional CI testing.

Since it does clean full KDE builds I didn't bother with triggers yet, the 
assumption is that the build takes longer than the average commit interval and 
that there are many more possible configuration combinations than active VMs 
anyway, which means there is no idle time ever. This can change though, if we 
manage to get a really high number of VMs deployed. OTOH the configuration 
space grows exponentially with every option we add.

> If successful it would be a great way to cover many of the possible
> configurations.

That's exactly the idea :)
 
> My vision:
> 
> A traditional CI system running on KDE HW.
> A system like this running configuration tests.
> Ideally these should be integrated so that the configuration test
> system only tests builds that have passed the CI system.

Yes, both approaches are complementary, I'd like to see them both implemented 
as well.

regards
Volker

["signature.asc" (application/pgp-signature)]

_______________________________________________
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem


[prev in list] [next in list] [prev in thread] [next in thread]