Re: nightly-release takes more than 24 hours to build.


Xu, Jiajun <jiajun.xu@...>
 

Hello,

Leading up to our 0.9 release, our autobuilder has been building an
increasing number of targets for our nightly-release buildset. We've
now reached the point that the nightly build takes more than 24 hours
to run (> 26 hours, in fact)
- which is clearly a problem on a build that we'd like to generate on
a daily basis.

The following is a list of everything which is built within nightly-release:

The following targets are built for qemux86, qemux86-64, qemuarm,
qemumips, and qemuppc:

* poky-image-minimal
* poky-image-sato
* poky-image-lsb
* poky-image-sdk
* meta-toolchain-sdk (SDKMACHINE=i586 and also x86_64)

For emenlow and atom-pc, we build:

* poky-image-minimal-live
* poky-image-sato-live
* poky-image-sdk-live
* meta-toolchain-sdk (SDKMACHINE=i586 and also x86_64)

Finally, we also build the Eclipse plugin, and copy the shared state
prebuilds and RPM output at the end of the build.

I was going to post build times for some of these targets for
reference, but it would be misleading as we build the targets in
succession (e.g, we start with poky-image-sdk which takes the bulk of
the time, and then the other targets can largely rely on the shared state builds).

Ideally I think our nightly build should take much less than 24 hours
to build. The question is what we can move out of the nightly build
and do on perhaps a weekly basis instead?
How about customizing the nightly build to build part of targets for every day? For example, x86/x86_64 for Monday, atom-pc/emenlow for Tuesday..... etc.
And we can schedule a new build task for weekly, which is only triggered on Wednesday(or maybe Tuesday night) for QA weekly testing and with all targets built out.

Our buildserver hardware is a dual quad-core Xeon server with 12 GB of RAM.
Throwing hardware at the problem is another solution, but not an
inexpensive one (we'd be looking at a 4-socket machine filled with
quad-cores and 32 GB of RAM).

I'm open to ideas on how to address this issue. QA will be driving a
lot of the requirements and I'm especially interested to hear your thoughts.

Scott


_______________________________________________
yocto mailing list
yocto@...
https://lists.pokylinux.org/listinfo/yocto
Best Regards,
Jiajun

Join yocto@lists.yoctoproject.org to automatically receive all group messages.