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
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
Only gccgo should be using this now, and hopefully not for too long.
Turn it off by default, and make it the only thing that happens
when it's switched on.
LGTM=bradfitz, cmang
R=bradfitz, cmang
CC=golang-codereviews
https://golang.org/cl/153940043
So the optimization to avoid hg clone works again. The
builder looks at buildroot+"goroot" for an hg clone repo. If
it finds it, it can just "hg pull" instead of a slow "hg
clone".
LGTM=cmang
R=cmang, proppy
CC=golang-codereviews
https://golang.org/cl/147960044
The 'parents' field is documented to be blank if there's only one
simple parent. We want 'p1node', which is the hex commit of the
first parent.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/142530043
Also add a added=true addition that I seemed to think was
previously missing.
Breaking this out of previous big CL.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/146080043
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
... since it already caught a problem and was fixed in
hg rev 0b99c2137ccc.
I pushed this live already just so don't get a whole column of
fail that might hide other issues. Real users have USER set
anyway. (Perhaps we should set it for all our builders?)
LGTM=adg
R=golang-codereviews
CC=adg, dave, golang-codereviews, minux
https://golang.org/cl/137180043
Otherwise when running -386 and -amd64 on the same machine
with both copies of TDM-GCC installed (the installer wizard lets
you choose which one, and you can do both options in two
different install attemps), one previously got this error when
using the 64-bit gcc with a 386 build:
--- FAIL: TestStdcallAndCDeclCallbacks (0.12s)
panic: Failed to load C:\Users\WINDOW~1\AppData\Local\Temp\1\TestCDeclCallback960696761\test.dll: %1 is not a valid Win32 application. [recovered]
panic: Failed to load C:\Users\WINDOW~1\AppData\Local\Temp\1\TestCDeclCallback960696761\test.dll: %1 is not a valid Win32 application.
goroutine 81490 [running]:
runtime.panic(0x5b8c00, 0x1390d4e0)
c:/gobuilder/windows-386-gce-b24422c8828f/go/src/pkg/runtime/panic.c:130 +0xed fp=0x12d99f78 sp=0x12d99f24
testing.func·006()
c:/go/src/pkg/testing/testing.go:421 +0x147 fp=0x12d99fd0 sp=0x12d99f78
----- stack segment boundary -----
runtime.panic(0x5b8c00, 0x1390d4e0)
c:/gobuilder/windows-386-gce-b24422c8828f/go/src/pkg/runtime/panic.c:98 +0x17a fp=0x12155e98 sp=0x12155e44
syscall.MustLoadDLL(0x1390b7c0, 0x4a, 0x2)
c:/go/src/pkg/syscall/dll_windows.go:62 +0x6c fp=0x12155eb8 sp=0x12155e98
runtime_test.(*cbTest).run(0x12155f24, 0x1213cc00, 0x1390b7c0, 0x4a)
c:/gobuilder/windows-386-gce-b24422c8828f/go/src/pkg/runtime/syscall_windows_test.go:399 +0x36 fp=0x12155ef4 sp=0x12155eb8
runtime_test.TestStdcallAndCDeclCallbacks(0x1213cc00)
c:/gobuilder/windows-386-gce-b24422c8828f/go/src/pkg/runtime/syscall_windows_test.go:448 +0x28e fp=0x12155fac sp=0x12155ef4
TBR=cmang
R=cmang
CC=adg, golang-codereviews
https://golang.org/cl/141070043
Creating a new disk is the major latency cost of creating a
new instance. If we reuse a previous disk image, the VM and
CoreOS boot much quicker and start building again.
So add a mode where we don't mark the disk as delete-on-death
when we create it, and we search for a suitably-named existing
one on creation and try to reuse it.
It's a cache, essentially. It's still stateless.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/135410043
Then make the coordinator and linux environment Makefiles have
an upload target. Amusingly, this actually worked: the Docker
images now tar + compress + upload over HTTP all in a stream,
without even knowing how large the resulting tar.gz will be until
it's done uploading.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/140200043
Remove subversion & use newer version of the builder which
makes -verbose direct all.bash output to stdout/stderr.
LGTM=cmang
R=adg, cmang
CC=golang-codereviews
https://golang.org/cl/140910044
They were from a time before we had the os/exec package, if
memory serves.
Also, make verbose also mean that the main build's stdout
and stderr go to the real stdout and stderr as well.
I'll want that for the Docker-based builder.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/135000043
Good checkpoint. Can now do builds by hand.
Next step is coordinator server in front of this, and things
to fire up beefy GCE instances running CoreOS and each build
in its own Docker container. See README for how to do a single
build.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/134870043
