We're running up against the 1MB value limit when serving the dashboard
front page. Rather than shard keys, just store a more compact
representation of the data.
Change-Id: Ib5a4db4b0b78ddfe711ecbb58dcf1eff18e1fd53
Reviewed-on: https://go-review.googlesource.com/14630
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Perf and Graphs buttons lead to pages with no useful information.
Change-Id: I455a3f43b5f0d14ea19319d8af9d3f1ad7243481
Reviewed-on: https://go-review.googlesource.com/14488
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Also link commits to github (nicer diff view).
Also remove some old Mercurial cruft.
Change-Id: I717900cd9cac9c6b5d08b0594d5adf29ed56eeb7
Reviewed-on: https://go-review.googlesource.com/11327
Reviewed-by: Chris Broadfoot <cbro@google.com>
Reviewed-by: Andrew Gerrand <adg@golang.org>
The coordinator will automatically start building sub-repos against
the stable releases once this dashboard is rolled out.
Fixesgolang/go#11197
Change-Id: I6f0735f842431a1c072d748f9073120812a03309
Reviewed-on: https://go-review.googlesource.com/11112
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The builder page is too wide. Even with the default interleaved
background color it's still easy to lose track of which commit
you're looking at.
Change-Id: I5bdc5d98e1abe141b5bd04b190e8a18e8fa92550
Reviewed-on: https://go-review.googlesource.com/9876
Reviewed-by: Andrew Gerrand <adg@golang.org>
This adds an RFC 3339 commit date for each revision represented in the
mode=json output of the dashboard. This is shown on the HTML version
of the dashboard, so it's already readily available, and its useful
when scraping the dashboard.
Change-Id: I7683ab76505b3dcd2395f54ec6f904a4a8d56617
Reviewed-on: https://go-review.googlesource.com/9012
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It went rogue.
Change-Id: Id616bfff5760788927283d9a2cd95a992db82053
Reviewed-on: https://go-review.googlesource.com/8973
Reviewed-by: David Crawshaw <crawshaw@golang.org>
It's been broken forever and polluting the dashboard.
Change-Id: I1ecb89694c27d36baae36c7da6256f9a66330735
Reviewed-on: https://go-review.googlesource.com/5980
Reviewed-by: Andrew Gerrand <adg@golang.org>
I cannot work out how to test this. I tried "goapp serve" but the local
instance says "tag not found".
Change-Id: I1f2585277e5a114753000901f22d6d1adba06611
Reviewed-on: https://go-review.googlesource.com/5050
Reviewed-by: Andrew Gerrand <adg@golang.org>
The populateBuildingURLs method would add dummy Result values for
in-progress builds. This fools the jsonHandler into thinking in-progress
builds are actually failed builds, but then the dummy results have no
LogHash field, so it generates bad output.
Fixes#9701
Change-Id: I5f849925a132c5dd28659d9885e77dc6ae70b6c4
Reviewed-on: https://go-review.googlesource.com/3415
Reviewed-by: Andrew Gerrand <adg@golang.org>
Also:
- Move the watcher to cmd/watcher (somehow this was missed earlier).
- Move dashboard package from the repo root to its own directory.
- Update docker build scripts. (Although not yet the version hashes in
the Dockerfiles; this leaves the docker builds broken, but they were
already broken after moving the builder to cmd/builder. They'll be
fixed in a followup CL after this one is submitted.)
Change-Id: I29a9758da1f3c60446e3ce18174c0df26e4d8325
Reviewed-on: https://go-review.googlesource.com/3077
Reviewed-by: Andrew Gerrand <adg@golang.org>
The Go wiki has moved to GitHub. Update links to use a golang.org/wiki/... target.
Change-Id: Iff7e1b2add469318f5e467aed5d1f3e67155b283
Reviewed-on: https://go-review.googlesource.com/2250
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Don't accept results from old builders once we cut over to the git
dashboard.
Change-Id: I1087b9fa174542ecfc7251c13f4319f51eca17b6
Reviewed-on: https://go-review.googlesource.com/1358
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Also bump the watcher version, so the old watcher doesn't try to write
to the new dashboard.
Change-Id: I7f62ad937fe162dadfd1222f56a3c5e493be9a61
Reviewed-on: https://go-review.googlesource.com/1357
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This adds a "Git" dashboard at "/git/", which has its own namespace for
datastore and memcache. Once we have pushed out the new git repositories
we will spin up a commit watcher and builders that point to the Git
dashboard.
Once we are ready to switch the dashboard over to the new Git builders,
the (*Dashboard).Context method will be changed to return "Git"
as the default namespace. The old builders will be retired, and the
new builders will be configured to report to "/" instead of "/git/".
At that point all our old data will still be available in the default
namespace, but hidden from view.
LGTM=dsymonds, cmang
R=bradfitz, cmang, dsymonds, adg
CC=golang-codereviews
https://golang.org/cl/183050043
The previous instance of this change was applied to the release branch.
I don't know why the codereview plugin allowed me to do this.
Thankfully we won't be using it for much longer.
TBR=dfc
R=dave
CC=golang-codereviews
https://golang.org/cl/175870044
This should fix the issue where results sub-repo results are clobbered
by subsequent commits. (Much like the previous fix, which only
fixed the issue for main repo commits.)
TBR=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/167440044
We're going to keep the old paths in the dashboard until
after Go 1.4 is out the door.
TBR=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/169240044
This fixes the issue where a builder would occasionally wipe out
the results from another builder.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/172150043
Rewrite performed with this command:
sed -i '' 's_code.google.com/p/go\._golang.org/x/_g' \
$(grep -lr 'code.google.com/p/go.' *)
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/170920043
The sendPerfFailMail function populated a dummy commit value and
then calls commonNotify, which then updated and stored that dummy
commit, hosing the original commit entity.
LGTM=rsc
R=rsc, bradfitz, dvyukov
CC=golang-codereviews
https://golang.org/cl/164960043
solaris-amd64-solaris11 has been the most stable builder,
by far, over the last 9 months. solaris-amd64-smartos is
stable too and it's our fastest builder.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=adg, dave, golang-codereviews
https://golang.org/cl/163280043
1. Add missing comma to empty records after addition of Ann column.
2. Fix off-by-one in commit range calculation.
Release tags refer to the last commit of the release,
so there is no need to subtract 1 from them.
TBR=adg
R=adg, bradfitz
CC=golang-codereviews
https://golang.org/cl/157120043
1. Don't interpolate missing data points,
instead just use the previous value for missing points.
Interpolation hides significant line jumps,
making it look like the jump is a result of several small changes.
2. Add annotations for significant changes.
LGTM=adg
R=adg
CC=golang-codereviews, iant, rsc
https://golang.org/cl/154360046
Use single query to fetch commit runs and metric runs (instead of individual selects).
Hopefully this enables some kind of prefetching.
But more importantly it allows to work around "gaps" in commit nums,
as we only fetch data that is actually in the database
and don't try to query all commit runs in the "gap".
LGTM=adg
R=adg
CC=golang-codereviews, rsc
https://golang.org/cl/159910045
Several changes as per Russ and Ian requests:
1. Fix almost broken ZoomIn/ZoomOut/Newer/Older with ability zoom in/out and move left/right w/o reloading (the 'explorer' attribute on graph).
2. Start the graph from the current release by default.
3. Allow to select the range of commits by specifying release range (e.g. go1.1 to go1.3 or go1.3 to tip).
4. Make it visually clear that you can select several benchmarks/metrics (replace select with a set of checkboxes).
5. Remove the "absolute" mode. Instead normalize all metrics to the start of the release (start becomes 1.0) and all subsequent changes are relative to it.
LGTM=adg
R=adg
CC=golang-codereviews, iant, rsc
https://golang.org/cl/159980043
As per Ian request:
>> Let's clearly separate the build numbers from the runtime numbers.
>> The build numbers are interesting but there are many things that
>> affect them. The runtime numbers are presumably stable.
LGTM=adg
R=adg
CC=golang-codereviews, iant, rsc
https://golang.org/cl/154440043
Initially both positive and negative changes had solid background (green and red).
Then we removed background of positive changes due to:
https://code.google.com/p/go/issues/detail?id=8624
However, Ian noted:
"I did intuitively understand that + was an increase and - was a
decrease. I did not notice how the numbers were segregated between
the third and fourth columns. Now that you point it out, it is
obvious. It would be more obvious if the numbers in the fourth column
were highlighted in green."
Give positive changes green *border* (not background),
so they are still visually distinguishable from negative even in grayscale.
This is especially beneficial for perf detail view,
because currently it looks like everything is either
negative or neutral in that view (only red and black).
LGTM=adg
R=adg
CC=golang-codereviews, iant, rsc
https://golang.org/cl/159970043
It looks like the partial Commits are coming from the build breakages mails.
If you have commit A newer than commit B, then there are two code
paths depending on which reports its build result first.
For slow development, B finishes before A is committed, so when
A notices a failure it checks to see if B was okay.
That code path seems to be okay.
For submit of back-to-back changes, typically A finishes before B,
so when B notices an okay it checks to see if A failed.
That code path seems to zero the Commit for A while
trying to set its FailNotificationSent to true.
It does (did) succeed in setting FailNotificationSent to true,
it just zeroed everything else.
This CL adds code to refuse to do the datastore.Put to
update FailNotificationSent if the Commit info is incomplete.
It also tries to ignore Num=0 records, but that may not be
as important anymore.
LGTM=cmang
R=cmang
CC=golang-codereviews
https://golang.org/cl/154080043
The UI template iterates over ResultGoHashes to display the Commit
rows. This was done for the sub-repository build view, where it
only makes sense to show a row when there's build data for it.
However, in the main page UI we do want to see if a commit has hit
the dashboard but has not yet been built.
This change causes the dashboard to show the commit row even if
there are no build results for it yet.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/153010043
This was a hold-over from when we removed install counts years ago.
All the Package entities are well-formed these days.
LGTM=dsymonds
R=dsymonds
CC=golang-codereviews
https://golang.org/cl/138620043
This is so that we don't corrupt our commit history with reports
from old builders, after the migration to the latest build dashboard.
LGTM=dvyukov
R=dvyukov
CC=golang-codereviews
https://golang.org/cl/130300043
Currently for every benchmark/metric we show all changes for all builders x procs.
With 4 builders and 5 procs, that's 20 changes (20 red/green boxes in a single cell).
Instead show only maximum change for every benchmark/metric.
This significantly reduces clutter in UI.
When you click on the red/green box, you can see the rest of the changes.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/126430043
Currently appspot logs say:
delay: gob encoding failed: gob: type build.PerfChange has no exported fields
And I was thinking why it is not sending mails...
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/125480043
Currently we still see some flakes on perf dashboard (e.g. sys-stack is quite frequent).
I am planning to run real perf builder with 5 different values of GOMAXPROCS,
so we can require 3 builders to agree on a change instead of 2.
This will provide 20x improvement in flake detection.
At the same time lower noise bar from 1.2 to 1.1, as I see some real perf changes gets ignored as noise.
All these magic numbers affect only representation of data, but not the data stored in DB.
So we can continue freely tuning them later. There are no significant risks here.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/127520044
This CL moves code from code.google.com/p/dvyukov-go-perf-dashboard,
which was previously reviewed.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/96170043
This CL moves code from code.google.com/p/dvyukov-go-perf-dashboard,
which was previously reviewed.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/96180043
This CL moves code from code.google.com/p/dvyukov-go-perf-dashboard,
which was previously reviewed.
UI part will be submitted separately.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/97260043
Andrew Gerrand
Alex Brainman
Shenghou Ma
Brad Fitzpatrick
Austin Clements
Chris Manghane
David Crawshaw
Emil Hessman
Brad Fitzpatrick
Dmitry Vyukov
Aram Hăvărneanu
Russ Cox