Buildfarm build_test script on an embedded device.

[Andrew Bartlett]

On Wed, 2011-10-05 at 10:53 +0200, Kai Blin wrote:
> On 2011-10-05 05:47, Andrew Bartlett wrote:
> > On Tue, 2011-10-04 at 22:24 -0500, Christopher R. Hertel wrote:
> >> Andrew Bartlett wrote:
> 
> I'm a bit late to the party here, but let me add some comments here.
> 
> >>> I think we should support devices this small, for small workloads, but
> >>> the Samba build process is not one of these, and the test process is
> >>> certainly not one of these.  
> 
> No, the current Samba top-level build doesn't even work on 128 MB of RAM
> without using swap. It actually might be nice to fix that at some point
> as well.
> 
> >>> To get better support for Samba on your dockstar, we should instead
> >>> ensure that an Arch Linux x64 machine is in the build farm, and if a
> >>> sufficiently fast and well-resourced host can be found, that an emulated
> >>> Arch Linux ARM machine is in the build farm.  The will help return
> >>> errors that developers can reproduce in a local VM (eg their python
> >>> insanity) and look at ARM portability issues.  
> 
> As Chris indicated, targeting 32bit might be worthwhile, current ARM
> platforms are 32bit. I think the focus on ArchLinux in the discussion is
> unfortunate, there's a lot of distros that are less braindead in their
> approach towards packaging python that also work on ARMv5.
> 
> ArchLinux shipping with a broken python default setting is an orthogonal
> problem, in my opinion.

Sure, it's also an orthogonal problem we can solve, which at least
allows me to propose some positive action from this activity :-)

> >> Note that the Dockstar is an ARMv5 and that the ARMv5 is somewhat out of
> >> date.  There are multi-core ARM processors out now.  I will see if I can get
> >> hold of something else to try.
> > 
> > Getting something with a lot of ram will help a lot. 
> 
> I've got a dual-core 1 GHz A9-Cortex box with 1 GB of RAM and an SSD
> drive. If that's not fast enough for the build farm, we can simply give
> up testing for embedded devices and tell people we don't support low-end
> systems.

How long does it take to build Samba on that?  

If it builds in reasonable time, I think we can improve the efficiency
of Samba and the test environment, or simply do less tests. 

> > If you just want to make the box available, then that's just a matter of
> > accepting SSH logins.  The trouble is that the build farm is very much a
> > one-size-fits-all solution right now, and the resource demands have
> > escalated dramatically in the 10 years I've been involved with it. 
> 
> Is this documented somewhere? Getting hold of a new system for the build
> farm just to get shot down a couple of days later seems like an
> inefficient approach to getting a box in.

Not really - I knew it would not be fast, but I guess I hadn't paid
close enough attention to the original compile run taking so long.
Until now the build farm has been made up of existing machines that
folks care to donate time on, rather than special purchases.

> If the build farm is not the place to make sure we support embedded
> devices, what _is_ the proposed method? Do I just run a cron-job based
> build on one of my systems that checks if make test worked and then
> emails all authors of the git commits between the last build that worked
> and the current one that failed?

The build farm would seem to be a good basis to start with, but it needs
a new owner who give it the care and attention that I don't manage to
provide.  It certainly is flexible enough to run different commands on
different hosts, and would be no less useful than a cron job.  However,
debugging anything other than trivial portability issues will almost
certainly require ssh access.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org