About autobuilder images


Tian, Kunwei <kunwei.tian@...>
 

Hi, Elizabeth
I find the folder 20101123-1 and folder 20101124-1 are empty,which from http://autobuilder.pokylinux.org/nightly/.
Do you know what is the matter? And also , I find folder 20101115-1 only have qemu images,but folder 20101115-2 is ok.
What is the different between folder 20101115-1 and folder 20101115-2?

Thanks,
Kunwei


Scott Garman <scott.a.garman@...>
 

Meant to cc: the list.

Scott

-------- Original Message --------
Subject: Re: [yocto] About autobuilder images
Date: Fri, 26 Nov 2010 20:48:35 -0700
From: Scott Garman <scott.a.garman@intel.com>
To: Tian, Kunwei <kunwei.tian@intel.com>

On 11/25/2010 01:55 AM, Tian, Kunwei wrote:
Hi, Elizabeth I find the folder 20101123-1 and folder 20101124-1 are
empty,which from http://autobuilder.pokylinux.org/nightly/. Do you
know what is the matter? And also , I find folder 20101115-1 only
have qemu images,but folder 20101115-2 is ok. What is the different
between folder 20101115-1 and folder 20101115-2?
Most likely you're looking at output from a build that was canceled.

Previously, the output directories in the web area were only created at
the very end of the buildset, and the images copied over in one big
step. However, due to the length of time builds were taking and our need
to make the images available to QA as quickly as possible, images are
now copied over to the web area in several steps (generally as each main
machine arch is completed).

The -1 vs. -2 directory naming definitely indicates that the first build
was originally canceled and a second one was run.

To make this clearer, I'm thinking at the start of the build to touch a
file named BUILD_INCOMPLETE or somesuch, and then delete that at the
very end of the build, to clarify the state of the build. I can probably
add this early next week.

Scott

--
Scott Garman
Embedded Linux Distro Engineer - Yocto Project


Elizabeth Flanagan <elizabeth.flanagan@...>
 

I looked into this this morning and that's exactly what he's seeing,
canceled builds. I agree that some way of ensuring that incomplete
builds aren't copied to nightly is needed, but I also think it's
important that we look at a different way to solve the issue of getting
nightly images to QA.

One idea that I'm bouncing around, is that we create a QA nightly that
consists of single arch targets (e.g. nightly-x86 nightly-arm
nightly-x86_64). It solves the problem of a single failing architechture
causing the entire nightly to fail and allows quicker turn around for
QA. It doesn't reduce the time for an entire nightly to run but it
shouldn't increase it either (as long as each target shares a common
buildtime directory), but it does make it so that if one thing fails in,
say x86, that the entire QA effort is not blocked. I'll have an RFC for
this by tomorrow morning that sketches this out in finer detail.

-b

On 11/26/2010 07:52 PM, Scott Garman wrote:
Meant to cc: the list.

Scott

-------- Original Message --------
Subject: Re: [yocto] About autobuilder images
Date: Fri, 26 Nov 2010 20:48:35 -0700
From: Scott Garman <scott.a.garman@intel.com>
To: Tian, Kunwei <kunwei.tian@intel.com>

On 11/25/2010 01:55 AM, Tian, Kunwei wrote:
Hi, Elizabeth I find the folder 20101123-1 and folder 20101124-1 are
empty,which from http://autobuilder.pokylinux.org/nightly/. Do you
know what is the matter? And also , I find folder 20101115-1 only
have qemu images,but folder 20101115-2 is ok. What is the different
between folder 20101115-1 and folder 20101115-2?
Most likely you're looking at output from a build that was canceled.

Previously, the output directories in the web area were only created at
the very end of the buildset, and the images copied over in one big
step. However, due to the length of time builds were taking and our need
to make the images available to QA as quickly as possible, images are
now copied over to the web area in several steps (generally as each main
machine arch is completed).

The -1 vs. -2 directory naming definitely indicates that the first build
was originally canceled and a second one was run.

To make this clearer, I'm thinking at the start of the build to touch a
file named BUILD_INCOMPLETE or somesuch, and then delete that at the
very end of the build, to clarify the state of the build. I can probably
add this early next week.

Scott