[Toaster] Removing 7844358 from toaster-next ("create Build object earlier in bitbake processing")

[Michael Wood]

Yes, let's remove  "toaster: create Build object earlier in bitbake 
processing" from toaster-next. If it's not going up to bitbake-devel in 
it's current form and It's causing a regression there isn't any point 
keeping it around in toaster-next.

Michael

On 04/04/16 09:24, Smith, Elliot wrote:
> 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 at intel.com 
> <mailto:elliot.smith at 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 at intel.com 
> <mailto:elliot.smith at intel.com>>
>     Signed-off-by: Michael Wood <michael.g.wood at intel.com 
> <mailto:michael.g.wood at intel.com>>
>
>
> -- 
> Elliot Smith
> Software Engineer
> Intel Open Source Technology Centre
>
>