<tt><font size=2>Maxime Ripard <maxime.ripard@free-electrons.com>
wrote on 11/10/2013 05:18:11 AM:<br>
<br>
> From: Maxime Ripard <maxime.ripard@free-electrons.com></font></tt>
<br><tt><font size=2>> To: Matthew Weber <mlweber1@rockwellcollins.com></font></tt>
<br><tt><font size=2>> Cc: Jérôme Pouiller <jezz@sysmic.org>,
buildroot@busybox.net</font></tt>
<br><tt><font size=2>> Date: 11/10/2013 05:20 AM</font></tt>
<br><tt><font size=2>> Subject: Re: [Buildroot] [RFC] Continuous integration</font></tt>
<br><tt><font size=2>> <br>
> Hi Matthew,<br>
> <br>
> On Fri, Nov 08, 2013 at 01:35:46PM -0600, Matthew Weber wrote:<br>
> > We might have a fourth semi-continuous integration scenario that
prevents <br>
> > server thrashing at each check-in. <br>
> > - We run the script every night processing the current GIT tip
at that <br>
> > time. <br>
> > - We clean each of the full cfg builds and let the script do
a complete <br>
> > re-build.  (We do this because the individual pkg  cleans
aren't <br>
> > guaranteed <br>
> > to cleanup the pkg installs)<br>
> > - Once all jobs complete we terminate the script and eventually
will send<br>
> > the report with status.<br>
> > (I'll clean-up what I changed and get it committed.  Would
you be up for <br>
> > optional runtime config options?  One might be to enable
continuous <br>
> > or a one-stop script execution.)<br>
> <br>
> It's pretty much what I've setup here already:<br>
> </font></tt><a href="http://jenkins.free-electrons.com/job/buildroot/"><tt><font size=2>http://jenkins.free-electrons.com/job/buildroot/</font></tt></a><tt><font size=2><br>
> <br>
> It runs every night and start a clean build of all the configuration<br>
> we have if a new commit has been merged.<br>
> <br>
> The only thing missing here is that the emails get only send to Peter,<br>
> Thomas P. and I because I didn't want to spam the list, but this can<br>
> easily be changed.<br>
> </font></tt>
<br><tt><font size=2>Cool, good to know that the default set of defconfigs
is being validated against</font></tt>
<br><tt><font size=2>the current tip.</font></tt>
<br><tt><font size=2>I think the scenario we're trying to target is validating
offline/internal </font></tt>
<br><tt><font size=2>board targets for different custom products.  We
don't necessarily want the builds</font></tt>
<br><tt><font size=2>to catch every commit (limited on build server resources),
but just give us granular</font></tt>
<br><tt><font size=2>enough feedback to know roughly which commit caused
a new issue.  </font></tt>
<br><tt><font size=2>We evaluated buildbot and Jenkins and had been debating
about just doing a </font></tt>
<br><tt><font size=2>simple script like what Jérôme has done.  So
when we saw what he had started it </font></tt>
<br><tt><font size=2>looked like a good opportunity to give it a try.  Currently
we have it setup for</font></tt>
<br><tt><font size=2>a nightly validation of a few defconfigs.  </font></tt>
<br><tt><font size=2>For a continuous integration, I do agree Jenkins is
a very good option.</font></tt>
<br>
<br><tt><font size=2>Thanks,</font></tt>
<br><tt><font size=2>Matt Weber</font></tt>
<br><tt><font size=2>mlweber1@rockwellcollins.com</font></tt>
<br><tt><font size=2><br>
> Maxime<br>
> <br>
> -- <br>
> Maxime Ripard, Free Electrons<br>
> Embedded Linux, Kernel and Android engineering<br>
> </font></tt><a href="http://free-electrons.com/"><tt><font size=2>http://free-electrons.com</font></tt></a><tt><font size=2><br>
> [attachment "signature.asc" deleted by Matthew L Weber/CedarRapids/<br>
> RockwellCollins] </font></tt>