Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/build/cmd/gomote: make environment complete enough to be usable #32430

Open
bcmills opened this issue Jun 4, 2019 · 4 comments
Open

x/build/cmd/gomote: make environment complete enough to be usable #32430

bcmills opened this issue Jun 4, 2019 · 4 comments

Comments

@bcmills
Copy link
Member

@bcmills bcmills commented Jun 4, 2019

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

gopher@SERVER-2016-V7- C:\workdir\go\src>make.bat
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

gopher@SERVER-2016-V7- C:\workdir\go\src>

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.

CC @golang/osp-team @aclements

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Jun 4, 2019

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.

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Jun 10, 2019

Change https://golang.org/cl/181542 mentions this issue: cmd/go: in TestScript, set $GOEXE instead of $exe

Loading

gopherbot pushed a commit that referenced this issue Jun 10, 2019
$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.

Updates #25300

Change-Id: I9d80f2a0fbaa8bc35fa2205b6898aeccecda4e94
Reviewed-on: https://go-review.googlesource.com/c/go/+/181542
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@gopherbot
Copy link

@gopherbot gopherbot commented Nov 15, 2019

Change https://golang.org/cl/207459 mentions this issue: dashboard, env, cmd/buildlet/testssh: fix gomote ssh for a number of buidlers

Loading

gopherbot pushed a commit to golang/build that referenced this issue Nov 15, 2019
…buidlers

And add a testssh tool to validate that SSH is working.

Updates golang/go#32430

Change-Id: I5182419fa4db31b598f7a02412fb4ecc4060a796
Reviewed-on: https://go-review.googlesource.com/c/build/+/207459
Reviewed-by: Bryan C. Mills <bcmills@google.com>
@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Nov 15, 2019

Related: I filed #35629 to make the Windows environments have their GUIs enabled, so RDP into them is more useful than a black cmd.exe on a black background.

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants