As part of my work to get grunt build running automatically on deploy,
I'm going to run it on Travis to make sure we catch things like this
before deploy :-)
This sets a dyanmic width for the job-tabs-panel so when non-Talos
jobs are selected, we optimize the resize experience at small browser
widths since only 4 tabs are visible.
When Talos jobs are selected, we increase the size accordingly
to accommodate 5 tabs.
Rather than just the summary text. Also removes the redundant bug
summary from the title (since it matches the link text) - which means
that there is no tooltip to show for bug suggestions unless the bugs are
resolved.
As of karma-jasmine 0.3.0, the jasmine library is not bundled with
karma-jasmine, and so jasmine-core has to be installed separately.
jasmine-jquery also has to be updated, since the old version was not
compatible. A duplicate jasmine-jquery file that was outside of the
tests vendor directory has also been removed.
We were applying the "pointer" style, which implied you could select
something when you couldn't before. We should only use that style when
hovering over the job buttons themselves. When hovering other parts
of the job group, use the "default" cursor which communicates that there
is nothing to click on or select.
When we had two series with the same signature on different branches, we
would incorrectly highlight two points on the same graph instead of
highlighting the relevant revisions on each. This used to work because
we associated a branch with each series signature, so could identify
them uniquely before, but we don't do this any more. Fortunately the fix here
is simple: just use the previously defined series instead of trying to
look it up all over again.
This would cause spurious navigation, which caused us to lose state when
loading the graphs view from a URL. This may have also been causing buggy
behaviour with the compare chooser locally.
* Stop storing mean/median/max/min for subtests as they're not always on the
same scale as the summary value
* Always use "filtered" value provided by Talos for subtest summary values
* Store value for tests as a "value" property for the series data
Stage/prod's robots.txt is currently served by Apache, and is in the
private puppet repo. Since Heroku can't use it, we need to check one
into our repo, that will then be served by WhiteNoise along with the
other static files.
The robots.txt file here is a direct copy of that currently at:
https://treeherder.mozilla.org/robots.txt
Once this change is deployed, we can remove the alias in the stage/prod
Apache config, leaving WhiteNoise to serve this file. As an added bonus,
it will also then be much easier for us to alter it in the future.
The issue with this bug was grouping, as it turns out. ``resultset_store`` was grouping jobs by their ``name`` and ``symbol``. However, we had the same ``symbol`` with two different names (one from Task Cluster, one from Buildbot). In this case, it was the ``?`` group which shows as not within any group.
Since the name from each source was different, we had 2 groups both with the symbol of ``?``. We would render the first one, then see another group named ``?`` and empty the first one, and add the new jobs.
What I've done is to fix both parts of that.
1. We group in ``resultset_store`` by *only* the group symbol to prevent conflicts there.
2. But if we DO, by magic, get two groups with the same symbol, then ``clonejobs.js`` can handle that. The fix for this is actually an optimization in that we didn't need to call ``.empty()`` where we did. Only in one circumstance did it actually make sense to do so. So I moved the call to ``.empty()`` there.
The latest version of django-browserid removes a view that we used to fetch to retrieve
basig config params for the browserid client initialization. We now have loginUrl and logoutUrl
hardcoded in the client and we fetch the user login status from a dedicated endpoint.
The parameter after "build:" is the block type, which is normally 'js',
'css' or a custom type. If we use a non-existent custom type (such as
"dontbuild"), grunt-usemin will just exclude the block, which is just
what we need to exclude this development-only file from the generated
assets used on stage/production.
See:
https://github.com/yeoman/grunt-usemin#blocks
The MPL 2.0 terms state that as long as a LICENSE file is present, the
per-file header text is not required. See "Exhibit A" at the end of:
https://www.mozilla.org/MPL/2.0/
Taskcluster logs are often missing step metadata for some of the log
content, so generic placeholder steps have to be created by the log
parser, that can be missing one or more of start time, finish time or
duration.
This branch aggregates non-failed jobs within groups and shows the counts of each result/state within.
A ``+`` precedes each count to indicate that's what it is.
A few points of interest:
* Clicking any group or count will expand or collapse the group. This choice is
remembered as jobs are updated and filters are changed. Page reload resets it.
* Clicking on the ``( + )`` and ``( - )`` buttons will toggle groups expanded/collapsed
globally. This is persisted in the URL. Clicking this button will reset any group
expand/collapse state that was set individually.
* Failed Unclassified jobs are never put into "counts". They show as top-level
jobs and are still hit with the ``n`` and ``p`` hot keys, etc.
Also fixes:
* Bug 1191454 - classifying 3 jobs, one selected, then clicking "n" for next will go to the first
* Bug 1191487 - Re-scroll selected job into view during chunk expand/collapse
This reverts commit 2e6b7b56c6.
* Allocate a smaller, fixed space for the bar graph (gives more
space for the test labels, which are often quite long)
* Make bar graph on a scale from 0-20% (with 20%+ regressions /
improvements consuming the full width)
* Add a tooltip documenting that we are only showing the relative
magnitude of the regression/improvement
* Show differences even if unsure (just show a greyed out bar chart
for those)
This branch aggregates non-failed jobs within groups and shows the counts of each result/state within.
A ``+`` precedes each count to indicate that's what it is.
A few points of interest:
* Clicking any group or count will expand or collapse the group. This choice is
remembered as jobs are updated and filters are changed. Page reload resets it.
* Clicking on the ``( + )`` and ``( - )`` buttons will toggle groups expanded/collapsed
globally. This is persisted in the URL. Clicking this button will reset any group
expand/collapse state that was set individually.
* Failed Unclassified jobs are never put into "counts". They show as top-level
jobs and are still hit with the ``n`` and ``p`` hot keys, etc.