We currently have this in toaster-next, but after discussion with RP, we've
agreed that this is probably not the right way to do this.

RP suggested a couple of alternatives, which I can look into this week (see
bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=8440).

For the moment, can I suggest that we remove this from toaster-next and
force push the branch?

NOTE: I'm mentioning this because it will mess up everyone's Toaster
database, as the patch included a migration. You'll need to remove any
existing db and start again. It will also affect Ed's branch, as he rebased
on toaster-next with this patch in it.

There is also a patch created by Michael which fixed an issue with my
patch, which I submitted to bitbake-devel last week. This failed to apply
because 7844358 wasn't accepted.

So this patch should also be ignored for now:
http://lists.openembedded.org/pipermail/bitbake-devel/2016-April/007258.html
I have already removed it from toaster-next.

Details of the commit I plan to remove are below for reference.

Elliot


commit 78443585bc92eca7140267126d53f749be3cdd6a
Author: Elliot Smith <elliot.smith@intel.com>
Date:   Thu Jan 28 16:21:01 2016 +0000

    toaster: create Build object earlier in bitbake processing

    If a build fails because of a bitbake error occurring before the
    BuildStarted event fires, we do not generate a Build object
    for command-line builds. This means that failed command-line builds
    don't appear in Toaster at all.

    To resolve, split build creation into two steps:

    1. Just before buildTargets() is invoked on the XMLRPC server: create
    the base Build object. Note that as soon as a Toaster-triggered
    build starts, targets are added to it; but this event is the earliest
    point when task and targets are available for command-line builds.
    (This requires a new TargetsAcquired event to be fired by the XMLRPC
    server when the buildTargets() command is called.)

    2. BuildStarted event: add any layer information to either type of build
    (command-line or Toaster-triggered).

    Note that the build_name property cannot be set until BuildStarted,
    as it is not available until then, which could cause problems
    for creating Build objects earlier; however, this property is
    redundant, as it's never used anywhere in Toaster, so it has been
    removed (along with any functions which refer to it).

    [YOCTO #8440]

    Signed-off-by: Elliot Smith <elliot.smith@intel.com>
    Signed-off-by: Michael Wood <michael.g.wood@intel.com>


-- 
Elliot Smith
Software Engineer
Intel Open Source Technology Centre