diff options
author | Elliot Smith <elliot.smith@intel.com> | 2016-06-29 15:41:56 +0100 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2016-08-11 00:09:26 +0100 |
commit | 952ffb3e1f4a00793e0c9c49bc0c8fb8729424c4 (patch) | |
tree | 604083d9477c9d3d2f51c714fe3b74ac8196f26c /bitbake/lib/toaster/orm | |
parent | c471740f5ba023dccc992438c75f1534950d26af (diff) | |
download | poky-952ffb3e1f4a00793e0c9c49bc0c8fb8729424c4.tar.gz |
bitbake: toaster: move most recent builds templating to client
The most recent builds area of the all builds and project builds
table needs to update as a build progresses. It also needs
additional functionality to show other states (e.g. recipe parsing,
queued) which again needs to update on the client side.
Rather than add to the existing mix of server-side templating
with client-side DOM updating, translate all of the server-side
templates to client-side ones (jsrender), and add logic which
updates the most recent builds area as the state of a build changes.
Add a JSON API for mostrecentbuilds, which returns the state of
all "recent" builds. Fetch this via Ajax from the build dashboard
(rather than fetching the ad hoc API as in the previous version).
Then, as new states for builds are fetched via Ajax, determine
whether the build state has changed completely, or whether the progress
has just updated. If the state completely changed, re-render the
template on the client side for that build. If only the progress
changed, just update the progress bar. (NB this fixes the
task progress bar so it works for the project builds and all builds
pages.)
In cases where the builds table needs to update as the result of
a build finishing, reload the whole page.
This work highlighted a variety of other issues, such as
build requests not being able to change state as necessary. This
was one part of the cause of the "cancelling build..." state
being fragile and disappearing entirely when the page refreshed.
The cancelling state now persists between page reloads, as the
logic for determining whether a build is cancelling is now on
the Build object itself.
Note that jsrender is redistributed as part of Toaster, so
a note was added to LICENSE to that effect.
[YOCTO #9631]
(Bitbake rev: c868ea036aa34b387a72ec5116a66b2cd863995b)
Signed-off-by: Elliot Smith <elliot.smith@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'bitbake/lib/toaster/orm')
-rw-r--r-- | bitbake/lib/toaster/orm/models.py | 44 |
1 files changed, 32 insertions, 12 deletions
diff --git a/bitbake/lib/toaster/orm/models.py b/bitbake/lib/toaster/orm/models.py index caacc2a544..2df6d4910a 100644 --- a/bitbake/lib/toaster/orm/models.py +++ b/bitbake/lib/toaster/orm/models.py | |||
@@ -592,22 +592,42 @@ class Build(models.Model): | |||
592 | 592 | ||
593 | return target_labels | 593 | return target_labels |
594 | 594 | ||
595 | def get_current_status(self): | 595 | def get_buildrequest(self): |
596 | """ | 596 | buildrequest = None |
597 | get the status string from the build request if the build | 597 | if hasattr(self, 'buildrequest'): |
598 | has one, or the text for the build outcome if it doesn't | 598 | buildrequest = self.buildrequest |
599 | """ | 599 | return buildrequest |
600 | 600 | ||
601 | def is_queued(self): | ||
601 | from bldcontrol.models import BuildRequest | 602 | from bldcontrol.models import BuildRequest |
603 | buildrequest = self.get_buildrequest() | ||
604 | if buildrequest: | ||
605 | return buildrequest.state == BuildRequest.REQ_QUEUED | ||
606 | else: | ||
607 | return False | ||
602 | 608 | ||
603 | build_request = None | 609 | def is_cancelling(self): |
604 | if hasattr(self, 'buildrequest'): | 610 | from bldcontrol.models import BuildRequest |
605 | build_request = self.buildrequest | 611 | buildrequest = self.get_buildrequest() |
612 | if buildrequest: | ||
613 | return self.outcome == Build.IN_PROGRESS and \ | ||
614 | buildrequest.state == BuildRequest.REQ_CANCELLING | ||
615 | else: | ||
616 | return False | ||
606 | 617 | ||
607 | if (build_request | 618 | def get_state(self): |
608 | and build_request.state != BuildRequest.REQ_INPROGRESS | 619 | """ |
609 | and self.outcome == Build.IN_PROGRESS): | 620 | Get the state of the build; one of 'Succeeded', 'Failed', 'In Progress', |
610 | return self.buildrequest.get_state_display() | 621 | 'Cancelled' (Build outcomes); or 'Queued', 'Cancelling' (states |
622 | dependent on the BuildRequest state). | ||
623 | |||
624 | This works around the fact that we have BuildRequest states as well | ||
625 | as Build states, but really we just want to know the state of the build. | ||
626 | """ | ||
627 | if self.is_cancelling(): | ||
628 | return 'Cancelling'; | ||
629 | elif self.is_queued(): | ||
630 | return 'Queued' | ||
611 | else: | 631 | else: |
612 | return self.get_outcome_text() | 632 | return self.get_outcome_text() |
613 | 633 | ||