[Toaster] Proposal: remove BuildRequest

[Smith, Elliot]

My thought is that we don't actually need BuildRequest. I've been thinking
about this for a while, and the complexity of the build cancellation has
made me wonder whether we should attempt this now.

Instead of using BuildRequest + Build, we just use a Build object, and
change its state according to where it has reached in its lifecycle. I have
got as far as:

QUEUED: build has been created and is waiting to be started; command-line
builds and Toaster builds both create Build objects set to this status

IN_PREPARATION: the targets have been sent to the XMLRPC server (recognised
via the TargetsAcquired event added for bug 8440), but parsing the recipes
etc. hasn't been done yet

IN_PROGRESS: the BuildStarted event has been received, so the build is
"properly" underway

CANCELLING: build is being cancelled

CANCELLED: build has been cancelled (end state)

SUCCEEDED: build completed successfully (end state)

FAILED: build failed (end state)

(I would also call the property which records the state "state", rather
than "outcome", but that's less important.)

If we removed build requests, we could get these benefits:

1. We could lose all the conditional code which checks for buildrequest
objects in Build objects, buildinfohelper, views, templates etc.

2. We could more easily capture the state of builds which haven't
"properly" started yet, and show a custom dashboard for them (bug 8443).
Currently, we don't have a state equivalent to IN_PREPARATION to cope with
this. I'm not sure of the best way to do this otherwise (put an artificial
BuildRequest on command-line builds?)

3. We can distinguish QUEUED builds from IN_PROGRESS builds in the recent
builds area without having to have code branches all over the place,
looking for build requests.

4. We can possibly get rid of all the brbe code (which doesn't apply to
command-line builds anyway).

5. When looking for a build to start (sticking with the runbuilds style
polling), we pick up the oldest QUEUED build, providing there are no builds
in any of the interim states (IN_PREPARATION, IN_PROGRESS, CANCELLING).
This would hopefully make runbuilds simpler, too.

In (5), we may have to deal with the situation where we want to trigger a
build but someone is starting one from the command line at the same time.
(Though I think we already have this problem anyway.) Michael's suggestion
of a command-line tool which effectively adds a new build to the queue via
Toaster's HTTP API could help here. But this would mean a user couldn't do
"bitbake <recipe>" and expect Toaster to be listening.

Any thoughts? It would be massively disruptive, granted, but I think we
could benefit from removing some unnecessary code.

Elliot
-- 
Elliot Smith
Software Engineer
Intel Open Source Technology Centre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/toaster/attachments/20160222/955a0987/attachment.html>