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
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
Currently performance builders crash with:
hg log: unmarshal Mercurial log: XML syntax error on line 4991: illegal character code U+001B
R=adg
CC=golang-codereviews
https://golang.org/cl/110060046
"PATH" and "path" are one and the same environment variable
on windows. We set PATH variable, while "path" is set to its
original value. Windows might use either for the sub-process.
LGTM=adg
R=golang-codereviews, adg
CC=golang-codereviews
https://golang.org/cl/109980043
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.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/97250044
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
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/95190043
1) Killing proceses on timeout was wrong: the os/exec
package will never return our package's error type
from its Wait.
2) fix a goroutine leak on timeout.
3) unexported an undocumented and elsewhere-unused type.
4) rename timeout type to end in "Error", per convention,
not Err.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/74290043
If we are building, for example, linux/386 on a linux/amd64 machine we want to make sure that the whole build is done as a if this were compiled on a real linux/386 machine. In other words, we want to not do a cross compilation build.
The exception to this rule is when we are doing nacl builds. These are by definition always cross compilation, and we have support built into cmd/go to be able to handle this case.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/74230043
Update golang/go#7372
This slipped into the build in revision 4b4229fc616b.
Thanks to @pierredurand87 for noticing the break.
LGTM=bgarcia
R=golang-codereviews, bgarcia
CC=golang-codereviews
https://golang.org/cl/66670043
Allow builder owners to set CGO_ENABLED to override the logic in cmd/go
LGTM=minux.ma, adg
R=golang-codereviews, minux.ma, adg
CC=golang-codereviews
https://golang.org/cl/63570046
It will save a lot of time for slow builders running on slow SD cards.
LGTM=dave, adg
R=golang-codereviews, dave, adg
CC=golang-codereviews
https://golang.org/cl/63550043
