go get build-lambda-zip is failing

[Dave-EMIS]

Sometime in the last 3/4 days we are no longer able to get build-lambda-zip

Repro Steps
On a clean machine (e.g. CodeBuild)

go get -u github.com/aws/aws-lambda-go/cmd/build-lambda-zip

Actual Result

# github.com/aws/aws-lambda-go/cmd/build-lambda-zip
go/src/github.com/aws/aws-lambda-go/cmd/build-lambda-zip/main.go:19:17: cannot use cli.StringFlag literal (type cli.StringFlag) as type cli.Flag in array or slice literal:
        cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)

Expected
No errors

[michael-mwp]

The issue occurred sometime prior to 11th October 21:17 UTC. Could this be a result of v1.13.3 released earlier that day?

[bmoffatt]

It might be that something changed on master for urfave/cli. I don't know if the go.mod file gets respected when using go get as described.

[bmoffatt]

I #249 fixed the problem. Let me know if it's still not working for you.

[Dave-EMIS]

Confirmed fixed on CodeBuild! Thanks @bmoffatt

[diegobernardes]

@Dave-EMIS, could you submit the output of go env? I want to dig more into this problem and I think that it is related to your environment/go settings.

[michael-mwp]

Also confirmed fixed on AppVeyor.

[Dave-EMIS]

@diegobernardes sure:

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/dave/.cache/go-build"
GOENV="/home/dave/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/dave/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/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-build640527069=/tmp/go-build -gno-record-gcc-switches"

This is from Ubuntu 18.04 on WSL - where I could also replicate the issue by doing cd ~ first.

I should point out that I didn't get an error when I did a go get inside my go module folder, only when I did it from another folder with no go modules. Which is the same on CodeBuild, we just have a go get ... in the install \ commands section to install it.

[diegobernardes]

@Dave-EMIS forgot to ask the Go version and the path you're using to build the code as well, but the problem is what you described, take a look at this sample:

➜  build-lambda-zip git:(master) pwd
/Users/diego/go/src/github.com/aws/aws-lambda-go/cmd/build-lambda-zip

➜  build-lambda-zip git:(master) git pull
Already up to date.

➜  build-lambda-zip git:(master) git checkout v1.13.3

Note: checking out 'v1.13.3'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at b5b7267 Add CloudWatch README (#242)

➜  build-lambda-zip git:(b5b7267) GO111MODULE=off go build main.go
# command-line-arguments
./main.go:19:17: cannot use cli.StringFlag literal (type cli.StringFlag) as type cli.Flag in array or slice literal:
	cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)

➜  build-lambda-zip git:(b5b7267) go build main.go

➜  build-lambda-zip git:(b5b7267) ✗ echo $?
0

If you're using Go:

• 1.13
  The code always gonna work as the go.mod is used. The only problem is if you set the GO111MODULE to off.

• 1.12
  Same thing as 1.13, but here we have another thing to care. If the code is inside the GOPATH, the default behavior is to not use the mod and with that, the dependencies gonna be downloaded from the master and can cause the problem you had. The same thing applies with GO111MODULE=off.

• Even older versions
  Don't know if aws-lambda-go support older versions of Go, but if it do, it gonna have the same behavior as the 1.12.

[Dave-EMIS]

We are using Go 1.13 on CodeBuild.

And we have it setup like this:

version: 0.2

env:
  parameter-store:
    GITHUB_TOKEN: GitHubToken
phases:
  install:
    runtime-versions:
      golang: 1.13
    commands:
      - go get -u github.com/aws/aws-lambda-go/cmd/build-lambda-zip
  pre_build:
    commands:
    - GO111MODULE=on
  build:
    commands:
      make out-code :)

We are quite new to go, but as I don't see a way to install Global Tools like you can on npm this is the approach we take to ensure it is there.
Having it in our go.mod and getting it that way makes it susceptible to been removed by a go mod tidy

[duaneking]

This issue should be reactivated.