Request for stable, automated build process

Bobby Martin bobbymartin2 at
Fri May 2 17:01:30 CEST 2008

On Fri, May 2, 2008 at 9:20 AM, Joachim Steiger <roh at> wrote:

> Michael 'Mickey' Lauer wrote:
> > This is all good and well, however there's one inherently problematic
> issue to
> > consider here. Continuous integration is very good and very possible
> (and we
> > need and will to use it to improve quality), however where it really
> shines
> > is, when the complete stack is under your control.
> >
> > Unfortunately (or rahter, luckily?), 80% of the Openmoko distribution
> actually
> > is not under Openmoko's control and we do not want to go and open a
> > repository and (effectively) fork all upstream projects.
> indeed.
> i thought of something more generic like bitbake invoking make check and
> put patches to add tests into the upstream packages into OE for now,
> with the goal for these to move upstream.
> after all, thats where tests belong and should be maintained.
> too bad the usual FOSS has a rather bad testcaseratio
> also i believe true CI will be problematic since the checkin rate is
> sometimes much higher than what buildhost could build. (cron triggered)
> --
> Joachim Steiger
> developer relations/support

I haven't been on a project where we pulled a significant amount of code
from repositories not under our control, and I agree that changes things
slightly.  It seems to me that it's more reason, not less, for CI, though.
(Really, I think you're already on the same track...)

Assuming that the outside repository doesn't already have a way to
find the latest good build, just use a dated pull from the repositories
outside your control, and record the "label" in a file.  Use the latest
good build date for the external code as your "label" to use when
building the code that *is* under your control.

You would probably want a separate CI process for each externally
controlled repository, plus one for all the OM controlled code.

Also, certainly for external code you would need to build on a
schedule, rather than restarting the build when new checkins
happen.  Really, you should probably do the same for your
internal code, too, though.  (With the caveat that you only
build your internal code at the scheduled time if changes have
been checked in).

If it doesn't make you smile, you're doing something wrong.
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the community mailing list