Uses a builder that can build both hg & git. (Should fix the git
subrepos on the main dashboard currently)
Change-Id: I3af96e35d40f6397625730b812a288f36622cb8a
Reviewed-on: https://go-review.googlesource.com/1203
Reviewed-by: Andrew Gerrand <adg@golang.org>
We're doing this so we can update the main builders to fix the
problems with subrepos. The coordinator doesn't know how to
pass -gcpath to this.
We can change it back to git after Go 1.4 is out.
Change-Id: I3924a34ac974cb77954acea4772ef0f52e36fa45
Reviewed-on: https://go-review.googlesource.com/1202
Reviewed-by: Andrew Gerrand <adg@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
This binary isn't intended to support hg anymore.
It almost might not support gccgo; I'm not sure.
But there'll be more work to do there anyway.
LGTM=dave, bradfitz, cmang
R=cmang, bradfitz, dave, adg
CC=golang-codereviews
https://golang.org/cl/181520043
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
The dashboard still uses the old "code.google.com/p/go.*" import paths.
Rewrite them to the new "golang.org/x/*" before running 'go get' and 'go test'.
Update golang/go#9079.
LGTM=rsc
R=rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/174740043
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
When the tree is particularly broken,
even the first invocation of bench binary that queries list
of benchmarks can hang.
Fixesgolang/go#8844.
LGTM=bradfitz
R=adg, bradfitz
CC=golang-codereviews
https://golang.org/cl/162160043
Current response logging logs either nil or pointer value
(e.g. "dash -> {0xc20802e058}"). Not very useful.
Log actual response data.
LGTM=bradfitz
R=adg, bradfitz
CC=golang-codereviews
https://golang.org/cl/163860043
Revision 184f9219148f (from review 152790043) introduced a new image,
linux-x86-clang, and the url is missing the `s` for TLS.
LGTM=adg
R=bradfitz, golang-codereviews, adg
CC=golang-codereviews
https://golang.org/cl/156480043
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
This change adds a 32-bit builder for gccgo and fixes some specific
configuration problems with the docker image/coordinator to speed up builds.
The go builder running on the linux-x86-gccgo image has been modified to run
`make -j16` when building to reduce build times from ~60 minutes to ~10 minutes
and the coordinator has been modified to run the command `make check-go -j16`
to reduce testsuite run times from ~30 minutes to ~10 minutes.
LGTM=bradfitz
R=bradfitz
CC=adg, golang-codereviews
https://golang.org/cl/151530043
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
