On Fri, May 2, 2008 at 9:20 AM, Joachim Steiger <<a href="mailto:roh@openmoko.org">roh@openmoko.org</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c">Michael 'Mickey' Lauer wrote:<br>
> This is all good and well, however there's one inherently problematic issue to<br>
> consider here. Continuous integration is very good and very possible (and we<br>
> need and will to use it to improve quality), however where it really shines<br>
> is, when the complete stack is under your control.<br>
><br>
> Unfortunately (or rahter, luckily?), 80% of the Openmoko distribution actually<br>
> is not under Openmoko's control and we do not want to go and open a<br>
> repository and (effectively) fork all upstream projects.<br>
<br>
</div></div>indeed.<br>
i thought of something more generic like bitbake invoking make check and<br>
put patches to add tests into the upstream packages into OE for now,<br>
with the goal for these to move upstream.<br>
after all, thats where tests belong and should be maintained.<br>
too bad the usual FOSS has a rather bad testcaseratio<br>
<br>
also i believe true CI will be problematic since the checkin rate is<br>
sometimes much higher than what buildhost could build. (cron triggered)<br>
<font color="#888888"><br>
--<br>
<br>
Joachim Steiger<br>
developer relations/support<br>
</font></blockquote></div><br>I haven't been on a project where we pulled a significant amount of code<br>from repositories not under our control, and I agree that changes things<br>slightly. It seems to me that it's more reason, not less, for CI, though.<br>
(Really, I think you're already on the same track...)<br><br>Assuming that the outside repository doesn't already have a way to<br>find the latest good build, just use a dated pull from the repositories<br>outside your control, and record the "label" in a file. Use the latest<br>
good build date for the external code as your "label" to use when<br>building the code that *is* under your control.<br><br>You would probably want a separate CI process for each externally<br>controlled repository, plus one for all the OM controlled code.<br>
<br>Also, certainly for external code you would need to build on a<br>schedule, rather than restarting the build when new checkins<br>happen. Really, you should probably do the same for your <br>internal code, too, though. (With the caveat that you only<br>
build your internal code at the scheduled time if changes have<br>been checked in).<br clear="all"><br>-- <br>If it doesn't make you smile, you're doing something wrong.