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
-- _______________________________________________ toaster mailing list [email protected] https://lists.yoctoproject.org/listinfo/toaster
