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

cmd/go: bazel wrapper disables build cache but not module mode #29850

Closed
uri-canva opened this Issue Jan 21, 2019 · 4 comments

Comments

Projects
None yet
4 participants
@uri-canva
Copy link

uri-canva commented Jan 21, 2019

What version of Go are you using (go version)?

$ go version
go version go1.11.4 darwin/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/uri/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/uri/go"
GOPROXY=""
GORACE=""
GOROOT="/Users/uri/github/buchgr/bazel-remote/output_user_root/7cad9a535094f3b591a5a672e5fc2afb/external/go_sdk"
GOTMPDIR=""
GOTOOLDIR="/Users/uri/github/buchgr/bazel-remote/output_user_root/7cad9a535094f3b591a5a672e5fc2afb/external/go_sdk/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/uri/github/buchgr/bazel-remote/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/0d/f45mrlw51yj0fn50bs44xych0000gn/T/go-build508525325=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

cd
mkdir -p github/buchgr
cd github/buchgr
git clone https://github.com/buchgr/bazel-remote.git
cd bazel-remote
git checkout 3f65b6ccf69e223950c77275a743d0d3a04a8583
# this will succeed
bazel fetch //:bazel-remote
# this will fail
bazel --output_user_root="$PWD/output_user_root" fetch //:bazel-remote

Once the above steps have been executed a more direct repro is available, though it needs to be adapted for the specific checkout:

$ pwd
/Users/uri/github/buchgr/bazel-remote
$ env -i GOROOT=/Users/uri/github/buchgr/bazel-remote/output_user_root/7cad9a535094f3b591a5a672e5fc2afb/external/go_sdk GOPATH=/Users/uri/github/buchgr/bazel-remote/output_user_root/7cad9a535094f3b591a5a672e5fc2afb/external/bazel_gazelle_go_repository_tools PATH=/Users/uri/.nix-profile/bin:/Users/uri/.cargo/bin:/Users/uri/bin:/Users/uri/.yarn/bin:/Users/uri/go/bin:/opt/datadog-agent/bin:/Users/uri/homebrew/opt/go/libexec/bin:/Users/uri/homebrew/opt/python/libexec/bin:/Users/uri/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin TMPDIR=/var/folders/0d/f45mrlw51yj0fn50bs44xych0000gn/T/ /Users/uri/github/buchgr/bazel-remote/output_user_root/7cad9a535094f3b591a5a672e5fc2afb/external/go_sdk/bin/go install github.com/bazelbuild/bazel-gazelle/cmd/fetch_repo
go: cannot use modules with build cache disabled
$ echo $?
1
$ cd ..
$ pwd
/Users/uri/github/buchgr
$ env -i GOROOT=/Users/uri/github/buchgr/bazel-remote/output_user_root/7cad9a535094f3b591a5a672e5fc2afb/external/go_sdk GOPATH=/Users/uri/github/buchgr/bazel-remote/output_user_root/7cad9a535094f3b591a5a672e5fc2afb/external/bazel_gazelle_go_repository_tools PATH=/Users/uri/.nix-profile/bin:/Users/uri/.cargo/bin:/Users/uri/bin:/Users/uri/.yarn/bin:/Users/uri/go/bin:/opt/datadog-agent/bin:/Users/uri/homebrew/opt/go/libexec/bin:/Users/uri/homebrew/opt/python/libexec/bin:/Users/uri/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin TMPDIR=/var/folders/0d/f45mrlw51yj0fn50bs44xych0000gn/T/ /Users/uri/github/buchgr/bazel-remote/output_user_root/7cad9a535094f3b591a5a672e5fc2afb/external/go_sdk/bin/go install github.com/bazelbuild/bazel-gazelle/cmd/fetch_repo
$ echo $?
0

What did you expect to see?

go install succeeded

What did you see instead?

go install failed

@oiooj

This comment has been minimized.

Copy link
Contributor

oiooj commented Jan 22, 2019

Why you ignore the OS environment? You can set GOCACHE env to solve this issue.

@bcmills

This comment has been minimized.

Copy link
Member

bcmills commented Jan 22, 2019

/Users/uri/github/buchgr/bazel-remote/go.mod exists, so with GO111MODULE unset (or set to auto) you are in module mode when in that directory, and not in module mode when in the parent directory.

env -i (and presumably bazel) unsets all of the environment variables that the go command uses to compute GOCACHE.

So the error message here is accurate: the build cache is disabled in both cases, and in module mode that causes the build to fail.

You should probably file an issue against bazel (at https://github.com/bazelbuild/bazel/issues). @jayconrod may already be aware of one.

@bcmills bcmills changed the title "cannot use modules with build cache disabled" error depending on working directory cmd/go: bazel wrapper disables build cache but not module mode Jan 22, 2019

@bcmills bcmills added the modules label Jan 22, 2019

@bcmills bcmills added this to the Unreleased milestone Jan 22, 2019

@jayconrod

This comment has been minimized.

Copy link
Contributor

jayconrod commented Jan 22, 2019

Closing this issue. As @bcmills said, the error message is accurate -- the build should fail if GOCACHE (or something it can be derived from) is not set.

FYI, fetch_repo is not meant to be a standalone tool. It's used by go_repository, and its interface may change in the future as go_repository gains better support for modules. Feel free to open an issue in github.com/bazelbuild/bazel-gazelle if you find a problem there.

@jayconrod jayconrod closed this Jan 22, 2019

@uri-canva

This comment has been minimized.

Copy link
Author

uri-canva commented Jan 23, 2019

Yes, master of gazelle already sets the right value for GOCACHE.

/Users/uri/github/buchgr/bazel-remote/go.mod exists, so with GO111MODULE unset (or set to auto) you are in module mode when in that directory, and not in module mode when in the parent directory.

Thank you, that explains everything: I did not expect go to interact with the working directory because I was installing a specific package, and not the package in the current working directory, but that makes sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment