On Fri, May 2, 2008 at 9:20 AM, Joachim Steiger <[EMAIL PROTECTED]> 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.
_______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community