2013-10-11 12:46:23 +00:00
|
|
|
<!DOCTYPE html>
|
|
|
|
|
{% load static %}
|
2015-06-08 17:33:44 +00:00
|
|
|
{% load projecttags %}
|
2015-10-02 07:14:42 +00:00
|
|
|
{% load project_url_tag %}
|
2014-10-02 16:58:15 +00:00
|
|
|
<html lang="en">
|
2015-11-13 15:28:07 +00:00
|
|
|
<head>
|
|
|
|
|
<title>
|
|
|
|
|
{% block title %} Toaster {% endblock %}
|
|
|
|
|
</title>
|
|
|
|
|
<link rel="stylesheet" href="{% static 'css/bootstrap.min.css' %}" type="text/css"/>
|
2016-04-12 14:56:43 +00:00
|
|
|
<!--link rel="stylesheet" href="{% static 'css/bootstrap-theme.css' %}" type="text/css"/-->
|
2015-11-13 15:28:07 +00:00
|
|
|
<link rel="stylesheet" href="{% static 'css/font-awesome.min.css' %}" type='text/css'/>
|
|
|
|
|
<link rel="stylesheet" href="{% static 'css/default.css' %}" type='text/css'/>
|
2014-11-25 10:12:46 +00:00
|
|
|
|
2015-07-31 12:09:04 +00:00
|
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
|
|
|
|
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8" />
|
|
|
|
|
<script src="{% static 'js/jquery-2.0.3.min.js' %}">
|
|
|
|
|
</script>
|
|
|
|
|
<script src="{% static 'js/jquery.cookie.js' %}">
|
|
|
|
|
</script>
|
|
|
|
|
<script src="{% static 'js/bootstrap.min.js' %}">
|
|
|
|
|
</script>
|
bitbake: toaster: work-around our lack of a synchronous fetch for typeaheads
The Twitter typeahead.js library expects the developer to use
a source which does a local search for matching suggestions, then
falls back to a remote search if that doesn't return enough
results.
However, in Toaster, we don't do any caching of the suggestions
for a typeahead, so our source only works in asynchronous mode.
Consequently, we see fewer than the expected number of suggestions
if the typeahead has already shown suggestions matching a query.
For example, searching for "meta-n" in the layers typeahead will
show the results for this query; but when the query changes to
"meta-ne", a new set of results is fetched, which mostly overlaps
with the results for "meta-n". The typeahead assumes that the
overlapping items are locally cached and have been delivered
synchronously, and just appends the new results which don't
overlap with the previous query. But because we don't provide any
results synchronously, we just end up with the single
non-overlapping result in the drop-down.
This can be fixed by hacking typeahead.js so that instead of
appending asynchronous results, we always overwrite and redraw
the whole typeahead menu.
This is a temporary fix, and should be properly fixed (when we
have time), perhaps by using typeahead.js's associated Bloodhound
library.
Added a note about the hack to the license file as an explanation
of why the unminified JS file is included in Toaster.
(Bitbake rev: afbaf326e1123c92952fa71e0e820a4ff83488ca)
Signed-off-by: Elliot Smith <elliot.smith@intel.com>
Signed-off-by: Michael Wood <michael.g.wood@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-04-18 15:59:05 +00:00
|
|
|
<script src="{% static 'js/typeahead.jquery.js' %}">
|
2016-04-12 11:07:01 +00:00
|
|
|
</script>
|
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>
2016-06-29 14:41:56 +00:00
|
|
|
<script src="{% static 'js/jsrender.min.js' %}">
|
|
|
|
|
</script>
|
2017-10-10 03:31:40 +00:00
|
|
|
<script src="{% static 'js/highlight.pack.js' %}">
|
2015-07-31 12:09:04 +00:00
|
|
|
</script>
|
|
|
|
|
<script src="{% static 'js/libtoaster.js' %}">
|
|
|
|
|
</script>
|
|
|
|
|
{% if DEBUG %}
|
|
|
|
|
<script>
|
|
|
|
|
libtoaster.debug = true;
|
|
|
|
|
</script>
|
2015-04-10 17:15:03 +00:00
|
|
|
{% endif %}
|
2015-07-31 12:09:04 +00:00
|
|
|
<script>
|
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>
2016-06-29 14:41:56 +00:00
|
|
|
$.views.settings.delimiters("<%", "%>");
|
|
|
|
|
|
2015-07-31 12:09:04 +00:00
|
|
|
libtoaster.ctx = {
|
|
|
|
|
jsUrl : "{% static 'js/' %}",
|
|
|
|
|
htmlUrl : "{% static 'html/' %}",
|
|
|
|
|
projectsUrl : "{% url 'all-projects' %}",
|
2015-08-04 19:46:34 +00:00
|
|
|
projectsTypeAheadUrl: {% url 'xhr_projectstypeahead' as prjurl%}{{prjurl|json}},
|
2015-07-31 12:09:04 +00:00
|
|
|
{% if project.id %}
|
|
|
|
|
projectId : {{project.id}},
|
2015-10-02 07:14:42 +00:00
|
|
|
projectPageUrl : {% url 'project' project.id as purl %}{{purl|json}},
|
2016-09-26 10:59:28 +00:00
|
|
|
xhrProjectUrl : {% url 'xhr_project' project.id as pxurl %}{{pxurl|json}},
|
2015-07-31 12:09:04 +00:00
|
|
|
projectName : {{project.name|json}},
|
2015-08-04 19:46:34 +00:00
|
|
|
recipesTypeAheadUrl: {% url 'xhr_recipestypeahead' project.id as paturl%}{{paturl|json}},
|
|
|
|
|
layersTypeAheadUrl: {% url 'xhr_layerstypeahead' project.id as paturl%}{{paturl|json}},
|
|
|
|
|
machinesTypeAheadUrl: {% url 'xhr_machinestypeahead' project.id as paturl%}{{paturl|json}},
|
2015-07-31 12:09:04 +00:00
|
|
|
projectBuildsUrl: {% url 'projectbuilds' project.id as pburl %}{{pburl|json}},
|
2015-12-07 18:43:15 +00:00
|
|
|
xhrCustomRecipeUrl : "{% url 'xhr_customrecipe' %}",
|
2015-07-31 12:09:04 +00:00
|
|
|
projectId : {{project.id}},
|
2016-04-06 16:46:32 +00:00
|
|
|
xhrBuildRequestUrl: "{% url 'xhr_buildrequest' project.id %}",
|
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>
2016-06-29 14:41:56 +00:00
|
|
|
mostRecentBuildsUrl: "{% url 'most_recent_builds' %}?project_id={{project.id}}",
|
2015-07-31 12:09:04 +00:00
|
|
|
{% else %}
|
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>
2016-06-29 14:41:56 +00:00
|
|
|
mostRecentBuildsUrl: "{% url 'most_recent_builds' %}",
|
2015-07-31 12:09:04 +00:00
|
|
|
projectId : undefined,
|
|
|
|
|
projectPageUrl : undefined,
|
|
|
|
|
projectName : undefined,
|
|
|
|
|
{% endif %}
|
|
|
|
|
};
|
|
|
|
|
</script>
|
2015-11-13 15:28:07 +00:00
|
|
|
{% block extraheadcontent %}
|
|
|
|
|
{% endblock %}
|
|
|
|
|
</head>
|
2014-02-28 13:55:46 +00:00
|
|
|
|
2016-04-12 14:56:43 +00:00
|
|
|
<body>
|
2013-10-11 12:46:23 +00:00
|
|
|
|
2015-11-13 15:28:07 +00:00
|
|
|
{% csrf_token %}
|
2016-06-02 13:26:16 +00:00
|
|
|
<div id="loading-notification" class="alert alert-warning lead text-center" style="display:none">
|
2015-11-13 15:28:07 +00:00
|
|
|
Loading <i class="fa-pulse icon-spinner"></i>
|
|
|
|
|
</div>
|
2015-05-21 17:44:18 +00:00
|
|
|
|
2016-04-12 14:56:43 +00:00
|
|
|
<div id="change-notification" class="alert alert-info alert-dismissible change-notification" style="display:none">
|
2016-10-06 00:08:53 +00:00
|
|
|
<button type="button" class="close" id="hide-alert" data-toggle="alert">×</button>
|
2015-11-13 15:28:07 +00:00
|
|
|
<span id="change-notification-msg"></span>
|
|
|
|
|
</div>
|
2015-07-31 12:09:12 +00:00
|
|
|
|
2016-04-12 14:56:43 +00:00
|
|
|
<nav class="navbar navbar-default navbar-fixed-top">
|
|
|
|
|
<div class="container-fluid">
|
|
|
|
|
<div class="navbar-header">
|
|
|
|
|
<button type="button" class="navbar-toggle collapsed" data-toggle="collapse" data-target="#global-nav" aria-expanded="false">
|
|
|
|
|
<span class="sr-only">Toggle navigation</span>
|
|
|
|
|
<span class="icon-bar"></span>
|
|
|
|
|
<span class="icon-bar"></span>
|
|
|
|
|
<span class="icon-bar"></span>
|
|
|
|
|
</button>
|
|
|
|
|
<div class="toaster-navbar-brand">
|
|
|
|
|
<a href="/">
|
|
|
|
|
<img class="logo" src="{% static 'img/logo.png' %}" class="" alt="Yocto logo project"/>
|
|
|
|
|
</a>
|
|
|
|
|
<a class="brand" href="/">Toaster</a>
|
2015-07-31 12:09:04 +00:00
|
|
|
{% if DEBUG %}
|
2016-04-12 14:56:43 +00:00
|
|
|
<span class="glyphicon glyphicon-info-sign" title="<strong>Toaster version information</strong>" data-content="<dl><dt>Git branch</dt><dd>{{TOASTER_BRANCH}}</dd><dt>Git revision</dt><dd>{{TOASTER_REVISION}}</dd></dl>"></i>
|
2015-07-31 12:09:04 +00:00
|
|
|
{% endif %}
|
2016-04-12 14:56:43 +00:00
|
|
|
</div>
|
|
|
|
|
</div>
|
|
|
|
|
<div class="collapse navbar-collapse" id="global-nav">
|
|
|
|
|
<ul class="nav navbar-nav">
|
|
|
|
|
{% if request.resolver_match.url_name != 'landing' and request.resolver_match.url_name != 'newproject' %}
|
2017-06-15 04:40:56 +00:00
|
|
|
<li id="navbar-all-builds"
|
|
|
|
|
{% if request.resolver_match.url_name == 'all-builds' %}
|
2016-04-12 14:56:43 +00:00
|
|
|
class="active"
|
|
|
|
|
{% endif %}>
|
2015-07-31 12:09:04 +00:00
|
|
|
<a href="{% url 'all-builds' %}">
|
2016-04-12 14:56:43 +00:00
|
|
|
<i class="glyphicon glyphicon-tasks"></i>
|
2015-07-31 12:09:04 +00:00
|
|
|
All builds
|
|
|
|
|
</a>
|
2016-04-12 14:56:43 +00:00
|
|
|
</li>
|
2017-06-15 04:40:56 +00:00
|
|
|
<li id="navbar-all-projects"
|
|
|
|
|
{% if request.resolver_match.url_name == 'all-projects' %}
|
2016-04-12 14:56:43 +00:00
|
|
|
class="active"
|
|
|
|
|
{% endif %}>
|
2015-07-31 12:09:04 +00:00
|
|
|
<a href="{% url 'all-projects' %}">
|
|
|
|
|
<i class="icon-folder-open"></i>
|
|
|
|
|
All projects
|
|
|
|
|
</a>
|
2016-04-12 14:56:43 +00:00
|
|
|
</li>
|
|
|
|
|
{% endif %}
|
2017-06-15 04:40:56 +00:00
|
|
|
<li id="navbar-docs">
|
2015-08-04 15:07:06 +00:00
|
|
|
<a target="_blank" href="http://www.yoctoproject.org/docs/latest/toaster-manual/toaster-manual.html">
|
2016-04-12 14:56:43 +00:00
|
|
|
<i class="glyphicon glyphicon-book"></i>
|
|
|
|
|
Documentation
|
2015-08-04 15:07:06 +00:00
|
|
|
</a>
|
2016-04-12 14:56:43 +00:00
|
|
|
</li>
|
|
|
|
|
</ul>
|
|
|
|
|
<a class="btn btn-default navbar-btn navbar-right" id="new-project-button" href="{% url 'newproject' %}">New project</a>
|
2015-12-07 16:06:01 +00:00
|
|
|
</div>
|
2015-11-13 15:28:07 +00:00
|
|
|
</div>
|
2016-04-12 14:56:43 +00:00
|
|
|
</nav>
|
2013-10-11 12:46:23 +00:00
|
|
|
|
2016-04-12 14:56:43 +00:00
|
|
|
<div class="container-fluid">
|
|
|
|
|
{% block pagecontent %}
|
|
|
|
|
{% endblock %}
|
2015-11-13 15:28:07 +00:00
|
|
|
</div>
|
|
|
|
|
</body>
|
2013-10-11 12:46:23 +00:00
|
|
|
</html>
|
