We should show Cloning (git clone --progress) Parsing (sends out parse start,progress,done events) Building ( task x of y is available) ? are there others states we need to show?
The only one I am missing from your list is "queued" (if all build envs are busy and the build needs to wait).
*** Bug 8242 has been marked as a duplicate of this bug. ***
Brian, are you suggesting that we show the progress of the git clones at the level of granularity provided by git, i.e. percentage of the clone done?
i think it would be nice. the clone can take awhile and freezing is one of the things that causes users sadness. depends on how hard it is to get to it.
I think we should update the "most recent builds" section using Ajax, as we do for ToasterTable. We want to be able to update parts of this section which aren't as straightforward as "update the progress bar": for example, we need different pieces of HTML to display for the different states. For that, the rendering on the client needs more to be more flexible and will use more data. There are at least three ways we could approach sending the response to the Ajax request. In each case, the client would update the most recent builds section from the response: 1. Render the HTML for each build on the server, and send that as the response. The new HTML then replaces the existing HTML via client-side scripting. 2. Send JSON in the response. Put templating on the client, and re-render the templates for the most-recent builds section using that JSON. 3. Send JSON back in the response and use client-side JavaScript to update the most recent builds section. 1 is simplest and quickest, but most messy in terms of separation of concerns. (HTML fragments over Ajax feels wrong.) 2 is more complex in the short term but cleaner long term. (I would personally put all the templating on the client, but the project never went that route, so this is probably most out of step with what we have.) 3 is more complex than, and more messy than, 1; simpler than 2; but possibly more flexible than 1 or 2. Given that we do all our rendering server-side anyway, I think 1 makes most sense, much as I dislike it. I just wanted to gather some agreement before I went that route.
There's a flaw in my reasoning above: using 1 won't allow for neat transitions in the progress bar, as the HTML is being junked every time it is updated. I will have to go for 3.
Created attachment 3279 [details] Design - Build states
Submitted patches to mailing list: https://lists.yoctoproject.org/pipermail/toaster/2016-July/004997.html