CL 73334 limited the number of files listed during a push, but there is
an offf-by-one. Only 4 files are listed, but the messages says "only
showed 5". Fix the check such that 5 files are listed.
Before:
2018/01/03 09:39:11 Remote doesn't have "src/cmd/vendor/github.com/google/pprof/internal/symbolizer/symbolizer_test.go"
2018/01/03 09:39:11 Remote doesn't have "src/regexp/example_test.go"
2018/01/03 09:39:11 Remote doesn't have "src/runtime/debug/stubs.go"
2018/01/03 09:39:11 Remote doesn't have "src/runtime/defs_netbsd_386.go"
2018/01/03 09:39:11 Remote doesn't have 7245 files (only showed 5).
After:
2018/01/03 10:19:28 Remote doesn't have "src/cmd/vet/testdata/shift.go"
2018/01/03 10:19:28 Remote doesn't have "src/syscall/ztypes_linux_mips64le.go"
2018/01/03 10:19:28 Remote doesn't have "src/os/os_unix_test.go"
2018/01/03 10:19:28 Remote doesn't have "src/runtime/duff_amd64.s"
2018/01/03 10:19:28 Remote doesn't have "src/runtime/rt0_dragonfly_amd64.s"
2018/01/03 10:19:28 Remote doesn't have 7079 files (only showed 5).
Change-Id: I0a2fa401883b609727a5bf3d72bac3d242bdecbd
Reviewed-on: https://go-review.googlesource.com/85757
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The .[56789] extentions are no longer used since Go 1.5. and the
object files are already covered by isGitIgnored.
Change-Id: I0f2fe2bc248a8a3f0b2bdc1b59dd31f2242a6797
Reviewed-on: https://go-review.googlesource.com/83695
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
After telling me about 5 files, I get the point:
the remote gomote needs ALL the files.
Change-Id: I5ec858b4e06170d946fb6a51b02ce27199b68b41
Reviewed-on: https://go-review.googlesource.com/73334
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Chris Broadfoot <cbro@golang.org>
Since Go 1.9, the cmd/go tool has rearranged and the Go build now
writes some auto-generated files in different places. Don't delete
these auto-generated files in a "gomote push".
Otherwise you can't iteratively:
* hack locally
* gomote push
* test remotely
... without getting remote errors about missing files.
Change-Id: Iaf4d03f4a2cde46f5022b63066186495b3ae2c01
Reviewed-on: https://go-review.googlesource.com/53070
Reviewed-by: Andrew Bonventre <andybons@golang.org>
This adds an SSH server to farmer.golang.org on port 2222 that proxies
SSH connections to users' gomote-created buildlet instances.
For example:
$ gomote create openbsd-amd64-60
user-bradfitz-openbsd-amd64-60-1
$ gomote ssh user-bradfitz-openbsd-amd64-60-1
Warning: Permanently added '[localhost]:33351' (ECDSA) to the list of known hosts.
OpenBSD 6.0 (GENERIC.MP) golang/go#2319: Tue Jul 26 13:00:43 MDT 2016
Welcome to OpenBSD: The proactively secure Unix-like operating system.
Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code. With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.
$
As before, if the coordinator process is restarted (or crashes, is
evicted, etc), all gomote instances die.
Not yet supported:
* scp (help wanted)
* not all host types are configured. most are. some will need slight
config tweaks to the Docker image (e.g. adding openssh-server)
Supports currently:
* linux-amd64 (host type shared by 386, nacl)
* linux-arm
* linux-arm64
* darwin
* freebsd
* openbsd
* plan9-386
* windows
Implementation details:
* the ssh server process listens on port 2222 in the coordinator
(farmer.golang.org), which is behind a GKE TCP load balancer.
* the ssh server library is github.com/gliderlabs/ssh
* authentication is done via Github users' public keys. It's assumed
that gomote user == github user. But there's a mapping in the code
for known exceptions.
* we can't give out access to this too widely. too many things are
accessible from within the host environment if you look in the right
places. Details omitted. But the Go team and other trusted gomote
users can use this.
* the buildlet binary has a new /connect-ssh handler that acts like a
CONNECT request but instead of taking an explicit host:port, just
says "give me your machine's SSH connection". The buildlet can also
start sshd if needed for the environment. The /connect-ssh handler
also installs the coordinator's public key.
* a new buildlet client library method "ConnectSSH" hits the /connect-ssh
handler and returns a net.Conn.
* the coordinator's ssh.Handler is just running the OpenSSH ssh client.
* because the OpenSSH ssh child process can't connect to a net.Conn,
an emphemeral localhost port is created on the coordinator to proxy
between the ssh client and the net.Conn returned by ConnectSSH.
* The /connect-ssh handler requires http.Hijacker, which requires
fully compliant net.Conn implementations as of Go 1.8. So I needed
to flesh out revdial too, testing it with the
golang.org/x/net/nettest package.
* plan9 doesn't have an ssh server, so we use 0intro's new conterm
program (drawterm without GUI support) to connect to plan9 from the
coordinator ssh proxy instead of using the OpenSSH ssh client
binary.
* windows doesn't have an ssh server, so we enable the telnet service
and the coordinator ssh proxy uses telnet instead on the backend
on the private network. (There is a Windows ssh server but only in
new versions.)
Happy debugging over ssh!
Fixesgolang/go#19956
Change-Id: I80a62064c5f85af1f195f980c862ba29af4015f0
Reviewed-on: https://go-review.googlesource.com/50750
Reviewed-by: Herbie Ong <herbie@google.com>
Reviewed-by: Jessie Frazelle <me@jessfraz.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The windows-amd64-2008 is the same OS as windows-amd64-gce but is an
auto-generated image.
TODO: 386 auto-generated Windows builders, and then maybe we'll move
TryBots to Windows Server 2016. One step at a time. This should be a
no-op. I verified performance is the same.
Updates golang/go#17513
Change-Id: I34984db14b87d03771e15465978b1687df6895f7
Reviewed-on: https://go-review.googlesource.com/41611
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Replace oauth2.NoContext (deprecated) with context.Background(),
which has been available for two consecutive releases.
Add more cloud.google.com/go packages to the cmd/coordinator
Dockerfile to fix an error building cmd/coordinator. A dependency is
not present in master of cloud.google.com/go, but was present in the
older revision, and was not getting checked out correctly during the
"go get" step. In addition, we were failing to fetch dependencies for
some packages that coordinator depends on. I added instructions for
hopefully doing this more systematically in the future.
Fix the gitmirror Dockerfile which has the same problem.
Change-Id: Id6c2220482350a686b87742ec7915c457a689e52
Reviewed-on: https://go-review.googlesource.com/40852
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The one remaining error reported by "go vet" is the un-canceled
context in cmd/coordinator/remote.go, which isn't an error.
Change-Id: Ie8d9269fc77203cf82d0a724dd33e4871a8113a7
Reviewed-on: https://go-review.googlesource.com/39350
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
For testing new builder images, this adds support to gomote to connect
to a buildlet directly, without going via the coordinator. If the
builder name contains a '@' character, the name is expected to be of
the form <build-config-name>@ip[:port].
Also update the gomote run -path docs while I'm here, since I always
forget the magic expansions (which at least are documentd in the
buildlet godoc). Copy them to the flags doc.
Change-Id: I50227855897106e1cc60c1881700866d5fddf2a5
Reviewed-on: https://go-review.googlesource.com/38775
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This lets us set a timeout on the HTTP request, which lets us time out the
writeSnapshot call in cmd/coordinator.
Fixesgolang/go#18812.
Change-Id: I370448df4d95130c9c5b30ba32459ce844a6c967
Reviewed-on: https://go-review.googlesource.com/36897
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Our builders are named of the form "GOOS-GOARCH" or
"GOOS-GOARCH-suffix".
Over time we've grown many builders. This CL doesn't change
that. Builders continue to be named and operate as before.
Previously the build configuration file (dashboard/builders.go) made
each builder type ("linux-amd64-race", etc) define how to create a
host running a buildlet of that type, even though many builders had
identical host configs. For example, these builders all share the same
host type (a Kubernetes container):
linux-amd64
linux-amd64-race
linux-386
linux-386-387
And these are the same host type (a GCE VM):
windows-amd64-gce
windows-amd64-race
windows-386-gce
This CL creates a new concept of a "hostType" which defines how
the buildlet is created (Kube, GCE, Reverse, and how), and then each
builder itself references a host type.
Users never see the hostType. (except perhaps in gomote list output)
But they at least never need to care about them.
Reverse buildlets now can only be one hostType at a time, which
simplifies things. We were no longer using multiple roles per machine
once moving to VMs for OS X.
gomote continues to operate as it did previously but its underlying
protocol changed and clients will need to be updated. As a new
feature, gomote now has a new flag to let you reuse a buildlet host
connection for different builder rules if they share the same
underlying host type. But users can ignore that.
This CL is a long-standing TODO (previously attempted and aborted) and
will make many things easier and faster, including the linux-arm
cross-compilation effort, and keeping pre-warmed buildlets of VM types
ready to go.
Updates golang/go#17104
Change-Id: Iad8387f48680424a8441e878a2f4762bf79ea4d2
Reviewed-on: https://go-review.googlesource.com/29551
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Also update all users, and rename another template field.
Includes changes to coordinator, gomote, and release.
Change-Id: I1c4408eadbcb83d61063a910dfa18cc395952bc2
Reviewed-on: https://go-review.googlesource.com/20976
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
buildenv.Environment type defines configuration options:
- Coordinator uses the GCE project name to lookup config. A custom
config name can be provided at runtime to override.
- The conventional prod and stage project names ('symbolic-datum-552'
and 'go-dashboard-dev') map to prod and staging configuration structs.
- Production and staging status is explicitly defined in configuration.
- GCS bucket names for buildlet, logs, and snapshots are
configurable.
Change-Id: I7e6d7874eb0bdfe35dbdd5fcf6212ab50d576b88
Reviewed-on: https://go-review.googlesource.com/19502
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
gomote push was broken for builders requiring go1.4 be installed
in their $HOME.
(This broke when I changed gomote to always go via the coordinator)
Change-Id: I7e0bc7de4038d89b109dc1732e96101b60d79ea5
Reviewed-on: https://go-review.googlesource.com/17826
Reviewed-by: Austin Clements <austin@google.com>
Now Close always means destroy.
The old code & API was a half-baked implementation of a (lack of)
design where there was a difference between being done with a buildlet
(with it possibly being reused by somebody else?) and you wanting to
nuke it completely. Unfortunately this just grew messier and more
broken over time.
This attempts to clean it all up.
We can add the sharing ideas back later when there's actually a design
and implementation. (We're not losing anything with this CL, because
nothing ever shared buildlets)
In fact, this CL fixes a problem where reverse buildlets weren't
getting their underlying net.Conns closed when their healthchecks
failed, leading to 4+ hour (and counting) build hangs due to buildlets
getting killed at inopportune moments (e.g. me testing running a
reverse buildlet on my home mac to help out with the dashboard
backlog)
Change-Id: I07be09f4d5f0f09d35e51e41c48b1296b71bb9b5
Reviewed-on: https://go-review.googlesource.com/14585
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
This creates a mechanism for clients (such as cmd/release and
cmd/gomote) to obtain buildlets via the coordinator. Previously
cmd/release and cmd/gomote could only create GCE VMs themselves, and
required the GCE project's credentials. In addition to the awkwardness
of needing to hand out the GCE credentials, it also meant ARM and
Darwin buildlets (which use the reverse buildlet pool) weren't usable.
Instead, this creates a new auth mechanism where the coordinator is
contacted over TLS with key pinning (the CA system isn't used) in the
same way that the reverse builders already dialed into the
coordinator, and then a "user build type" and hash are sent as the
username and password. The same master key is used to sign user
builder keys, and they always start with "user-". (which isn't a GOOS).
Then the coordinator provides an API to create and list buildlets.
They auto-expire after a duration and are auto-renewed upon use.
The buildlet library (as used by cmd/release etc) then proxies HTTP
requests via the coordinator to the backend buildlet.
See doc/remote-buildlet.txt for protocol details.
Change-Id: I12e27eae788fdd91927cb182b950893dc759f8e9
Reviewed-on: https://go-review.googlesource.com/11901
Reviewed-by: Andrew Gerrand <adg@golang.org>
Also gomote updates which came about during the process of developing
and debugging this.
Change-Id: Ia53d674118a6b99bcdda7062d3b7161279b6ad52
Reviewed-on: https://go-review.googlesource.com/10463
Reviewed-by: Andrew Gerrand <adg@golang.org>
Everything is a VM now. Remove checks. Those accessors are gone.
Change-Id: I4089bf7f04a9138d35bfd2ade5de084796f2906b
Reviewed-on: https://go-review.googlesource.com/5591
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Add gomote and buildlet support for listing remote files, and
efficiently syncing from the local workstation to the remote buildlet.
Change-Id: Ifab1fb1c208ca4bc66f8d6916c38e1914001a3a5
Reviewed-on: https://go-review.googlesource.com/4270
Reviewed-by: Andrew Gerrand <adg@golang.org>
And use it in gomote and release tools.
Change-Id: I87fa013d6d6729e7305dacd137be1b3d3b02f5f4
Reviewed-on: https://go-review.googlesource.com/3771
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The 'build' repo (unlike the 'tools' repo) is allowed to depend on
anything.
Change-Id: I4caa9fe61bccf05f488152eac53ed5769a848d4d
Reviewed-on: https://go-review.googlesource.com/3113
Reviewed-by: Brad Fitzpatrick <bradfitz@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>
- get tarballs out of buildlets
- gomote can pass arguments to buildlet's exec handler
- buildlet's exec handler can run system-level commands
- hard-code GOROOT_BOOTSTRAP to be "go1.4" under the workdir
- adjust MTU size on GCE
etc
Change-Id: I73e18b7a5e395a889f5ee93ba9850d331ffb7812
Reviewed-on: https://go-review.googlesource.com/3052
Reviewed-by: Andrew Gerrand <adg@golang.org>
Client + server support, and gomote flags.
Change-Id: I91320f47731f8c69b84c4961028bfbbdfc85467a
Reviewed-on: https://go-review.googlesource.com/3029
Reviewed-by: Andrew Gerrand <adg@golang.org>
Tobias Klauser
Russ Cox
Brad Fitzpatrick
Josh Bleecher Snyder
Kevin Burke
Keith Randall
Andrew Gerrand
Evan Brown
Chris Manghane
Brad Fitzpatrick