[Systems] Buildfarm

[Sascha Silbe]

Excerpts from Bernie Innocenti's message of Wed Sep 15 16:08:37 +0200 2010:

> Ah, I did not get that you made it run again... so let's keep this VM
> around. It would be good to move this VM to bender, if you have the time
> to do it.

OK. Feel free to set up a new one on bender if the current one bugs you.
I don't have much time currently and moving VMs is lo-prio unless they
disturb other services.

> BTW: bender was down. There was a UPS failure at Develer and it did not
> boot automatically. Aleph seems to have fixed it today.

At least we don't need to schedule a reboot due to kernel update
anymore. ;)

> > I don't particularly care where the buildbots are running. In the long
> > run we should move to chroots anyway, to make sure we got the
> > dependencies right.
> 
> I do agree. Aleksey says that chroots for several distros could come for
> free out of bazaar (our OpenSuSE Build Service instance).

I don't think they're going to be particularly useful. To me, the
buildbots are testing not only Sugar, but also sugar-jhbuild. So a
chroot running a buildbot should use exactly the set of packages
sugar-jhbuild wants. Fewer packages would make it break (obviously) and
more packages would mean potentially not detecting missing dependencies
(like currently).

> (1) send email to systems-logs when a build fails that was previously
> working. After we made sure it works reliably, we could make it post to
> sugar-devel, so people will know when something caused a regression

It currently sends to me privately and I verify manually. Unfortunately
there are loads of false positives because

a) JHBuildbot is strongly centralised and doesn't integrate with our
   system dependencies hack, so it builds packages that are skipped
   on real systems
b) Nobody bothers to fix some of the issues that keep breaking builds
   [1-3] (or most of the Blocker bugs in general)


> (2) Output binary packages for testers.

I originally planned to do that, but now I think a better approach is
to base on the upstream packaging and tools instead. For Debian I have
already set this up, but due to unfortunate timing (Squeeze getting
frozen right before Sugar 0.89/0.90 could get packaged) I am currently
unable to test these without introducing local changes. The latest
snapshot packages that worked are running more or less fine on my
XO-1.5 however.

> Building for the sake of it is pretty pointless, since we don't have
> that much of an automated testsuite.

It's not quite true, and the lack of test suites is something we need
to fix anyway. I will try to land the sugar-datastore test suite right
after we branched off in for 0.92 (which hopefully will happen directly
after 0.90.0 is released, not several months afterwards like for
0.88/0.90).

> My sense is that we never will, because automated testing of
> GUI applications is an immature science. We need actual humans to test
> packages in real work conditions and file bug reports accordingly.

I don't think this is a contradiction. Automated tests for basic
operation are easy enough to implement (albeit time consuming) and very
useful. That is to say increasingly useful as the number of contributors
that are not time-proven Sugar hackers is rapidly increasing (which is
good in itself!).

> (3) interface with git to start builds only when necessary.

Yes, that would be very nice to have and the basic Buildbot software
even supports that. Only JHBuildbot (the mix between JHBuild and
Buildbot) doesn't support it. Patches welcome.

> (4) lower scheduling priority and I/O bandwidth so we don't need
> dedicated hardware for this service (my goal is to consolidate sugarlabs
> on fewer servers to reduce our admin overhead)

+1 on tweaking the priority. I would however always put build services
on a separate, low-priority server. So we could consolidate the
sugar-jhbuild build slaves and OBS on a single server (and maybe even
the keyserver), but I would advise against putting it on the same
machine as high-priority services like the wiki or a.sl.o.

Sascha

[1] https://bugs.sugarlabs.org/ticket/1414
[2] https://bugs.sugarlabs.org/ticket/1942
[3] https://bugs.sugarlabs.org/ticket/1239
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
Url : http://lists.sugarlabs.org/private/systems/attachments/20100915/6afea496/attachment.pgp