Every time I gomote ssh into an windows-amd64-2016 instance, I end up needing to run a bunch of boilerplate just to get make.bat to work:
~/go/src$ mote create windows-amd64-2016
~/go/src$ mote put14
~/go/src$ mote push
2019/06/04 11:55:19 Remote doesn't have "src/cmd/internal/obj/addrtype_string.go"
2019/06/04 11:55:19 Remote doesn't have "src/cmd/vendor/golang.org/x/sys/unix/syscall_linux_amd64.go"
2019/06/04 11:55:19 Remote doesn't have "test/fixedbugs/bug145.go"
2019/06/04 11:55:19 Remote doesn't have "test/fixedbugs/issue18725.go"
2019/06/04 11:55:19 Remote doesn't have "test/fixedbugs/issue4518.go"
2019/06/04 11:55:19 Remote doesn't have 8590 files (only showed 5).
2019/06/04 11:55:19 Remote lacks a VERSION file; sending a fake one
2019/06/04 11:55:22 Uploading 8591 new/changed files; 21554175 byte .tar.gz
~/go/src$ mote ssh
Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.
gopher@SERVER-2016-V7- C:\Users\gopher>cd C:\workdir\go\src
gopher@SERVER-2016-V7- C:\workdir\go\src>set CGO_ENABLED=0
gopher@SERVER-2016-V7- C:\workdir\go\src>set GOROOT_BOOTSTRAP=C:\workdir\go1.4
Building Go cmd/dist using C:\workdir\go1.4
Building Go toolchain1 using C:\workdir\go1.4.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
Building Go toolchain2 using go_bootstrap and Go toolchain1.
Building Go toolchain3 using go_bootstrap and Go toolchain2.
Building packages and commands for windows/amd64.
Installed Go for windows/amd64 in C:\workdir\go
Installed commands in C:\workdir\go\bin
That's five commands for what is logically only one operation: “give me an instance of windows-amd64-2016 set up to test my current GOROOT”.
On top of that, I end up needing to run that sequence repeatedly because the instance keeps rotting away out from under me (#28365).
That makes it really difficult to debug fixes, and produces a strong incentive to just run TryBots instead, wasting resources.
There are elements of Windows-specific stuff to this issue, but the more general issue (if I risk overloading this one) is that each gomote environment should be audited to be usable. Perhaps more code should be shared so that the gomote environments can't rot, or as easily.
Also, IIRC, gomote to BSDs ssh in as "gopher" or some non-root user with pwd in /home/gopher but the buildlets run as root, in /work ($WORKDIR). That should also be made consistent, one way or another.
Tests would be nice too, even if they were manual integration tests we run occasionally by hand.
$GOEXE exists and is documented in 'go env', so $exe is redundant and
a bit confusing. Notably, mod_modinfo.txt already assumes that GOEXE
is set (even though it isn't), and thus fails on Windows.
After this CL, `go test cmd/go/...` passes on a windows-amd64-2016
builder. However, given that the $PATH on the builder is very minimal
(#32430) and network access is limited, tests that rely on binaries
(such as 'git') or external networking may still be broken.
Run-TryBot: Bryan C. Mills <firstname.lastname@example.org>
TryBot-Result: Gobot Gobot <email@example.com>
Reviewed-by: Ian Lance Taylor <firstname.lastname@example.org>