hashicorp / levant

An open source templating and deployment tool for HashiCorp Nomad jobs
Mozilla Public License 2.0
830 stars 125 forks source link

Running go get github.com/hashicorp/levant causes cannot assign error. #352

Closed rzellmer closed 4 years ago

rzellmer commented 4 years ago

Description We have been using 'go get github.com/jrasell/levant/ in our build script for at least a year but it started to fail in last few days. We see you changed repo to hashicorp so we changed our build script accordingly 'go get github.com/hashicorp/levant' but the simple go git fails. In order to make sure it wasn't our build environment(we run under github actions) I also build a bare EC2 instance with just git and go on it. We get the exact same error in both environments so I was thinking it might not be user error on my side.

Error returned is below. We get this error in both our regular build environment and a virgin EC2 instance with just git and go.

../go/src/github.com/hashicorp/levant/template/render.go:28:11: cannot assign "github.com/hashicorp/nomad/vendor/github.com/hashicorp/nomad/api".Job to job (type "github.com/hashicorp/nomad/api".Job) in multiple assignment

jrasell commented 4 years ago

Hi @rzellmer and thanks for raising this issue. I have been able to successfully perform this action locally as the CI master build is work as expected. I removed the vendor directory at the tail end of last week to make dependancy management easier as well as keep it inline with our other projects. I would therefore expect this issue to no longer be present. Are you still seeing this issue within your build environment?

rzellmer commented 4 years ago

@jrasell - I am still having issues. FYI main build run under github actions. Maybe this is not a bug in your side but some change I need to make to my setup so i included some of my yml file used by github actions. I do still get the above warning/error about multiple assigns but the hard fail is a little further down when I try to run the deploy /home/runner/go/bin/levant deploy \. At that point it cant find the right directory. Maybe I just need to repoint the deploy? I did post a similar question on stackoverflow and there were some comments about $GOROOT. https://stackoverflow.com/questions/63531365/go-get-fails-for-hashicorp-levant/63535700?noredirect=1#comment112363290_63535700

Error That I see that fails the build- /home/runner/work/_temp/bf5eab64-0eb8-4c15-8431-ad4706d19bf8.sh: line 3: /home/runner/go/bin/levant: No such file or directory

[error]Process completed with exit code 127.

Relevant Part of Nomad Deploy yml used by Github Actions

jrasell commented 4 years ago

@rzellmer is the GitHub Action log output available to look at? Are you able to add go env somewhere in the run so we can take a look at what the Go environment looks like? This will provide some very useful information to hopefully help identify the problem.

rzellmer commented 4 years ago

Here is fulll log after adding go env. I think this can also be replicated easily on a blank ec2 env, I will document that separately.

Install CD Tools go env
 go get github.com/hashicorp/levant && go install github.com/hashicorp/levant sudo apt install -y -qq -o Dpkg::Use-Pty=0 fwknop-client

shell: /bin/bash -e {0} env:
 AWS_DEFAULT_REGION: AWS_REGION: AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY: SSH_AUTH_SOCK: /tmp/ssh-auth.sock

GO111MODULE=""
 GOARCH="amd64" GOBIN="" GOCACHE="/home/runner/.cache/go-build" GOENV="/home/runner/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/runner/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/opt/hostedtoolcache/go/1.14.7/x64" GOPROXY="https://proxy.golang.org,direct" GOROOT="/opt/hostedtoolcache/go/1.14.7/x64" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/opt/hostedtoolcache/go/1.14.7/x64/pkg/tool/linux_amd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="" 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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build472158305=/tmp/go-build -gno-record-gcc-switches"

github.com/hashicorp/levant/template

../../../go/src/github.com/hashicorp/levant/template/render.go:28:11: cannot assign "github.com/hashicorp/nomad/vendor/github.com/hashicorp/nomad/api".Job to job (type "github.com/hashicorp/nomad/api".Job) in multiple assignment

The following additional packages will be installed: libfko3

The following NEW packages will be installed: fwknop-client libfko3 0 upgraded, 2 newly installed, 0 to remove and 11 not upgraded. Need to get 94.0 kB of archives. After this operation, 251 kB of additional disk space will be used. Selecting previously unselected package libfko3. (Reading database ... 258548 files and directories currently installed.) Preparing to unpack .../libfko3_2.6.9-2_amd64.deb ... Unpacking libfko3 (2.6.9-2) ... Selecting previously unselected package fwknop-client. Preparing to unpack .../fwknop-client_2.6.9-2_amd64.deb ... Unpacking fwknop-client (2.6.9-2) ... Setting up libfko3 (2.6.9-2) ... Setting up fwknop-client (2.6.9-2) ... Processing triggers for man-db (2.8.3-2ubuntu0.1) ... Processing triggers for libc-bin (2.27-3ubuntu1.2) ...

———

Deploy to Staging

[error]Process completed with exit code 127.

Run fwknop -A tcp/22 -R -D --key-rijndael --wget-cmd /usr/bin/wget [*] Creating initial rc file: /home/runner/.fwknoprc. Warning: Permanently added '***' (ECDSA) to the list of known hosts. /home/runner/work/_temp/eec00cd1-cdf1-4e86-ba3b-40f22905ed50.sh: line 3: /home/runner/go/bin/levant: No such file or directory

[error]Process completed with exit code 127.

rzellmer commented 4 years ago

Is there anything you think we can do on our end to address this or do you think this requires a change in the repo? I did try starting with a virgin amazon ec2 instance, just installing git and go and running go get github.com/hashicorp/levant && go install github.com/hashicorp/levant - It throws that same multi assign error even on that ec2 instance.

We are in a weird spot where we run this from inside github actions with each deployment to staging/prod so this interesting situation is blocking our releases. Thanks for any consideration.

jrasell commented 4 years ago

@rzellmer I have found what the error is; I am just trying to find the time to figure out the best way to fix it. It's related to a change in the way Nomad handles its dependancies and so is an annoying type of fix.

A workaround would be to use git and make rather than the go module tooling for the time being. The steps would be:

If you're unable to use this workaround, I could be push a branch with a hack fix for the time being for you to use, although this would remove some of the functionality of render (the jobparse) but get you going. Please let me know.

rzellmer commented 4 years ago

@jrasell - thanks.. that change does allow for an install without error. My next step fails looking for levant as I assume it is now being installed in different folder but that is something I will investigate running it off github and on an ec2 instance.

Warning: Permanently added '***' (ECDSA) to the list of known hosts. /home/runner/work/_temp/f808c719-35bf-4d2e-ac63-23f11cf80c3c.sh: line 3: /home/runner/go/bin/levant: No such file or directory

jrasell commented 4 years ago

@rzellmer the make build command will output the binary to the bin directory within the checked out repository. So after make build you should be able to run something like ls ./bin from the directory and see the binary.

rzellmer commented 4 years ago

@jrasell if you think you can easily make the hack branch I will gladly take it. I want to see if that stabilizes the install location inside github actions. It appears the above workaround, when used inside github actions, installs levant in a folder that is dynamically assigned which means I cant easily access it later in the script. I am still digging deeper in to github actions and hope to be able to figure this out but if not difficult to make your fix, even in a hacky way I will gladly take it to see if it make it easier to run inside github actions

rzellmer commented 4 years ago

I was able to get my builds back using the workaround above. If anyone else is running levant in github actions it seem the levant folder ends up as

/home/runner/work/repo_name/repo_name/levant/bin/levant