From: "Jérôme Pouiller" <jezz@sysmic.org>
To: buildroot@busybox.net
Subject: [Buildroot] [RFC] Continuous integration
Date: Thu, 07 Nov 2013 14:37:21 +0100 [thread overview]
Message-ID: <1649802.VKqnEsp2qV@sagittae> (raw)
In-Reply-To: <CAC2S8khWpEpUZiYOrzE2agTXehwW+g5Pkncqdp2PRsc25bT-cw@mail.gmail.com>
On Tuesday 05 November 2013 10:29:52 Matt Weber wrote:
> On Fri, Oct 25, 2013 at 7:46 AM, J?r?me Pouiller <jezz@sysmic.org>
wrote:
> > Hello,
>
> <snip>
>
> > Code is available there:
> > https://github.com/jerome-pouiller/br-continuous
>
> We've been giving your script a try and made some updates. So I went
> ahead and created a (github)fork (should have a few updates checked in
> tonight).
Thanks for your interest.
> I fixed a couple items that may have been bugs (or possibly just how I
> used the script). I current have been running into an issue where
> after git updates are detected, previously built pkgs try to rebuild
> without doing a clean. I see where the conditional is that should be
> executing the clean but haven't tracked down why I'm not hitting that
> path yet.
By the way, it's difficult to find the right place to do a clean.
- Between each package, it take to much time.
- After any changes on git. But, for packages with many dependencies
(like qt5webkit), it means we will have to wait at least 3h per
configuration to have results. However, this solution is simple and
guarantee reproducibility of builds.
- Currently, I check if a clean happens since last build (in reality,
not any kind of build) of package. If it not the case, I launch make
clean.
> I also noticed that once the script processes all jobs it gets into a
> loop, I added a fix for that that prevents running the jobs unless
> there are still jobs to execute in the job list.
Good point. I will merge that.
> I noticed there isn't a good way to restart the script after you stop
> it, is my understanding correct? I (temporarily) added a cleanup
> sequence before the mainloop executes to remove history and each cfgs
> build before proceeding.
Normally, current implementation should work. It should populate
database with previous results. It is just long to launch (20min on my
server !). It would be better to change format of results to improve
launch time.
> I think there might be a bug with detecting when a package fails to
> build, I'll see if I can resolve this and let you know. I haven't had
> a package actually error yet, but have had some that never built
> because of host dependency error or download error
I did not noticed that.
> I was wondering what your thoughts were for the report? I'm guessing
> what's currently committed was the start of something based on this
> thread of discussion. I could see gathering a list of package err,
> git id, and list to build output (similarly to the autobuilder
> results).
List of all package errors would be too long. I think report should only
include package status changes (OK -> KO, N/A -> KO, but also KO -> OK).
Report should also report configuration changes after "yes | make
oldconfig".
Currently my main problem is execution of "yes | make oldconfig". In
case "y" is not a valid answer, this command will loop infinitely (and
"yes '' | make oldconfig" is not a good solution since i want to build
new packages).
--
J?r?me Pouiller, Sysmic
Embedded Linux specialist
http://www.sysmic.fr
next prev parent reply other threads:[~2013-11-07 13:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-25 12:46 [Buildroot] [RFC] Continuous integration Jérôme Pouiller
2013-10-28 6:50 ` Arnout Vandecappelle
2013-10-28 9:47 ` Jérôme Pouiller
2013-10-29 21:14 ` rjbarnet at rockwellcollins.com
2013-11-05 16:29 ` Matt Weber
2013-11-07 13:37 ` Jérôme Pouiller [this message]
2013-11-08 19:35 ` Matthew Weber
2013-11-10 11:18 ` Maxime Ripard
2013-11-11 13:53 ` Matthew Weber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1649802.VKqnEsp2qV@sagittae \
--to=jezz@sysmic.org \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox