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
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
Only send mail to golang-dev if updating the CL fails.
R=golang-codereviews, dvyukov, minux.ma, rsc
CC=golang-codereviews
https://golang.org/cl/43760043
Ensure that we do not split UTF-8 rune in half.
Otherwise appengine python scripts will break badly.
R=adg, r
CC=golang-dev
https://golang.org/cl/42530043
When fetching repos it is not uncommon for a 500 or 503 to be returned
from code.google.com. When this happens, log the error and continue so
that we try again later, rather than treating this as fatal.
R=adg, dvyukov
CC=golang-dev
https://golang.org/cl/38720044
This change is a really nasty hack to preserve the magic header
across requests. The nasty hack will go away once we refactor these
tests to use the new "appengine/aetest" package instead.
R=golang-dev, dvyukov
CC=golang-dev
https://golang.org/cl/39230043
`svn update` would fail if the updated files were in the gcc/libgo or gcc/go/gofrontend because unrevisioned versions of those files had been inserted in the last build of gcc.
R=adg, adg
CC=golang-dev
https://golang.org/cl/14299043
Downloading the GCC repo takes a lot of time and everything works fine if we just store it in the buildRoot and reuse it.
R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/13583045
This change adds a new build dashboard url to the existing appengine app: $dashurl/gccgo/ which will show the build status of gccgo.
* Added Dashboard struct with exported Name, Rel(ative)Path, and Packages fields.
* Added Dashboard Context method that returns an appengine context with a namespace corresponding to the dashboard's name.
* Modified HandlerFuncs to use Dashboard's Context method for all appengine requests.
* Modified ui template to show different title/header for separate dashboard and added dashboard tab.
R=adg
CC=golang-dev
https://golang.org/cl/13753043
* Added --tool flag that allows user to specify "gccgo" as the tool to build.
* Added builderEnv struct to abstract away setting up the build.
* Made envv and envvWindows methods of the builderEnv struct.
* Modified Builder.envv() to wrap envv and envvWindows
* Added internal builderEnv in Builder.
R=adg
CC=golang-dev
https://golang.org/cl/13240044
To make the dashboard more flexible with different VCS, the Repo now depends on the VCS package for running commands.
* Exported Repo.Master
* Modified RemoteRepo to return a repo and an error
* Reimplemented all Repo methods using vcs package
* Removed hgCmd
* Removed repoURL
* Removed scheme from hgUrl since vcs.RepoRootForImportPath decides the scheme.
* Changed waitWithTimeout into timeout
* Added waitForFuncWithTimeout to wrap vcs commands with a timeout.
R=adg
CC=golang-dev
https://golang.org/cl/13201043
Moving misc/dashboard to its new home. It will be deleted
(except for misc/dashboard/codereview) from its current home
if this is approved.
R=golang-dev, bradfitz, cmang, adg
CC=golang-dev
https://golang.org/cl/12180043
