[go-nuts] Re: Getting "$GOPATH/go.mod exists but should not" when running build in a Docker image
The `golang` container image sets the GOPATH directory to /go and the working directory to /go too. Following GOPATH layout, source code is expected to be in directories under /go/src. `/go/bin` is where binaries are installed by default, and `/go/pkg` include things like the module cache. With modules, it is entirely possible to work outside of the GOPATH (as you most likely are doing). In which case, a common pattern is to choose your own working directory, eg `WORKDIR /workspace` and work in there. On Friday, February 11, 2022 at 7:51:00 PM UTC+1 davidmic...@gmail.com wrote: > I had earlier written a note about troubles refactoring my project to have > a "src" directory, but I've backed off on that for now. I see that the > main problem I saw with that hasn't changed when backing out those changes. > It appears that running this build inside a docker image seems to be > somehow causing this problem. > > In any case, I have a relatively simple go application with main.go, > go.mod, and go.sum in the root directory, with subdirectories containing > other source files in packages. > > When I just run "go build ..." from the command line in the root directory > of my project, it works fine and produces a working executable. > > However, I'm trying to get this build to work within a published go > "builder" image, which I will use as the first stage in a multi-stage > Docker build. > > I will first state that this has something to do with GOPATH, and I've > gone through > https://www.digitalocean.com/community/tutorials/understanding-the-gopath > , but I'd have to say that I still don't understand its proper role here. > > Not sure what you would want to see first, but here's a plain "ls" of the > root directory of my project: > - > ./ Dockerfilego.mod JenkinsfileREADME.md > ../ .dockerignorego.sum lib/ > target/ > app/ .git/handlers/ main.gotrustStore/ > config/ .gitignoreinclude/ Makefilefuncs/ > --- > > Just running "make build" does this: > - > CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -o > ../target/dist/linux-amd64 > - > > Which is fine. > > My "dockerbuild" target in the Makefile is this: > > dockerbuild: > docker build \ > --build-arg host_src_path=. \ > --build-arg packages=. \ > --build-arg executable_name=appgo \ > --build-arg cgo_enabled_01=1 \ > --build-arg goos=linux \ > --build-arg goarch=amd64 \ > -f Dockerfile -t appgo . > --- > > My Dockerfile, before the start of the second build stage, is this: > > FROM .../golang:1.17.6-bullseye as go-builder > > ARG packages > ARG executable_name > ARG host_src_path > ARG cgo_enabled_01 > ARG goos > ARG goarch > > COPY $host_src_path . > RUN env > RUN ls -lt > RUN ls -lt $GOPATH > #RUN go mod download > > RUN CGO_ENABLED=$cgo_enabled_01 GOOS=$goos GOARCH=$goarch go build > -o $executable_name $packages > > > When I run "make dockerbuild", I see this: > -- > Sending build context to Docker daemon 125.8MB > Step 1/19 : FROM .../golang:1.17.6-bullseye as go-builder > ---> 80d9a75ccb38 > Step 2/19 : ARG packages > ---> Using cache > ---> d98015e225b1 > Step 3/19 : ARG executable_name > ---> Using cache > ---> 1d336ac5cf1b > Step 4/19 : ARG host_src_path > ---> Using cache > ---> 59595b09a376 > Step 5/19 : ARG cgo_enabled_01 > ---> Using cache > ---> 3c4c08392ede > Step 6/19 : ARG goos > ---> Using cache > ---> 6ed0d6881fb4 > Step 7/19 : ARG goarch > ---> Using cache > ---> 9e4b94e86b09 > Step 8/19 : COPY $host_src_path . > ---> 4727e2fc3e80 > Step 9/19 : RUN env > ---> Running in 8fcedaa86227 > HOSTNAME=8fcedaa86227 > HOME=/root > packages=. > cgo_enabled_01=1 > goarch=amd64 > host_src_path=. > > PATH=/go/bin:/usr/local/go/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin > goos=linux > GOPATH=/go > executable_name=appgo > PWD=/go > GOLANG_VERSION=1.17.6 > Removing intermediate container 8fcedaa86227 > ---> 46e44a5a3539 > Step 10/19 : RUN ls -lt > ---> Running in 75107286d337 > total 128 > -rw-rw-r-- 1 root root 635 Feb 11 18:37 Dockerfile > -rw-rw-r-- 1 root root 737 Feb 11 18:29 Makefile > -rw-rw-r-- 1
[go-nuts] Re: Weird GOPATH issue with go 1.8.
Run `type go` to see if `go` is an alias or function that is executing the go binary with GOPATH set. On Saturday, March 4, 2017 at 3:25:34 PM UTC-8, Bruno Albuquerque wrote: > > Something appears to be broken: > > $ echo $GOPATH > /home/bga/go-dev > > $ echo $GOBIN > /home/bga/go-dev/bin > > $ go env > GOARCH="amd64" > GOBIN="" > GOEXE="" > GOHOSTARCH="amd64" > GOHOSTOS="linux" > GOOS="linux" > GOPATH="/home/bga/go" > GORACE="" > GOROOT="/usr/local/go" > GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64" > GCCGO="gccgo" > CC="gcc" > GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 > -fdebug-prefix-map=/tmp/go-build654996623=/tmp/go-build > -gno-record-gcc-switches" > CXX="g++" > CGO_ENABLED="1" > PKG_CONFIG="pkg-config" > CGO_CFLAGS="-g -O2" > CGO_CPPFLAGS="" > CGO_CXXFLAGS="-g -O2" > CGO_FFLAGS="-g -O2" > CGO_LDFLAGS="-g -O2" > > Note that go env reports a different GOPATH. Also GOBIN is not set in it. > If I try to "go get" something, it ends up in /home/bga/go instead of > /home/bga/go-dev. > > Any ideas? > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: on GOPATH
Responses to a question like this tend to be either very detailed, or vague. This one has all the gory details. I develop under Linux. I'm happy to use fancy visual tools, but I also do a lot of stuff from the command line. I have a directory GOCODE where I put stuff that I fetch via go get. I set this up In my .profile, and put the bin directory in my path along with the Go bin directory: GOPATH=$HOME/gocode export GOPATH PATH=/usr/local/go/bin:$HOME/gocode/bin:$PATH export PATH (Under Linux you can create a variable and export it in one command, but that doesn't work across all UNIX systems.) You may want to include your go tools bin directory in the path as well. With this .profile, once I'm logged in, I have a GOPATH variable containing my gocode directory. I keep each of my Go projects in a separate directory. In the top level directory of each project I create a file setenv.sh containing this: if test -z $GOPATH then GOPATH=`pwd` export GOPATH else GOPATH=$GOPATH:`pwd` export GOPATH fi PATH=`pwd`/bin:$PATH export PATH That notation `pwd` in grave accents, means the current directory, so I can just copy this file from one project to another and it will work, as long as you run it from the right directory. To set up GOPATH for a project, I start a command window, change directory to the project and run the commands in setenv.sh: . setenv.sh (Note the "." at the start - see later about that.) If GOPATH doesn't already exist, it's created and contains just the current directory. If it exists, the current directory is added. Then the local bin directory is added to my path. YOU NEED TO BE IN THE RIGHT DIRECTORY, the top level of your project (the one that contains src, pkg, bin etc.) For example, if my project is $HOME/project1 and my .profile is set up as above, then GOPATH would contain something like /home/simon/gocode:/home/simon/project1 Now the go command can find my project and anything I've downloaded via "go get". My PATH variable will contain /home/simon/project1/bin:(whatever was already in the path) so any command that I build within this command window is in my path. In my .profile I set up the path to include the go and gocode bin directories, so that stuff is in my path too. Strictly, I don't need the setenv.sh file. I could just cd to the right directory and run this command by hand: GOPATH=$GOPATH:`pwd` As long as you cd to the right directory first. In fact the main purpose of creating the setenv.sh files is to remind me which directory I should be in when I run the commands! If GOPATH contains a colon-separated list of directories as above, "go get" uses the first one in the list. In my case that will always be my gocode directory, because I set it up that way in my .profile, and my setenv.sh files ensure that it's kept as the first directory. That means I can run "go get" in any command window and it will always put stuff in the same place. If I run a tool such as liteide from my command window having run setenv.sh, it picks up the GOPATH that I set up. If you use an IDE (liteide, eclipse, intellij or whatever) then you can simply set up a local GOPATH variable in the ide. The technique I describe above is not quite so slick, and depends upon you remembering to run the commands in setenv.sh before you start working, but if you still want the option of running commands from a command window, you need something like this. A note for people who are not Linux shell experts: setenv.sh looks like a shell script, but it isn't. If you ran it as a shell script it wouldn't work. Any variables that a shell script set up are lost when the shell script ends, so your script would set up GOPATH and then discard it. You need to run setenv.sh using the "." command as above. I've used all sorts of UNIX magic here - shell if commands, running commands in grave accents, running commands using "." and so on. If you are working under Windoze, none of this will work, but you can do similar stuff using batch files. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
