[Systems] Buildfarm

Bernie Innocenti bernie at codewiz.org
Wed Sep 15 10:08:37 EDT 2010


On Wed, 2010-09-15 at 11:21 +0200, Sascha Silbe wrote:
> > This buildslave is currently running a snapshot of maverik, not lucid.
> Yes, I didn't come around to / care enough to rename it yet.
> 
> > Since we already have a VM called usr which is running maverik, for the
> > sake of conserving resources I propose tearing down this VM and using
> > usr also as a build slave.
> 
> So my work in getting it to work again is lost? ^^
> Feel free to do it if you set up the buildbot in the USR VM. :-P

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.

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


> 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).

If we overwhelm the buildfarm, I'd like to see the following
enhancement:

(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

(2) Output binary packages for testers. Building for the sake of it is
pretty pointless, since we don't have that much of an automated
testsuite. 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.

(3) interface with git to start builds only when necessary. We have an
average of one commit per day in the sugar repositories, probably there
are entire weeks in which nothing changes. So we're wasting a lot of
computer resources

(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)

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/




More information about the Systems mailing list