Support go modules if a go.mod is present

[dougnukem]

Go modules is looking to be the standard tool for managing dependencies and will be built into the go build toolchain.

• https://github.com/golang/go/wiki/Modules

The action could support go modules if the action detects go.mod

If a repository has modules it is expected to run the build outside the $GOPATH, otherwise it has to inject environment variables to force the go tooling to use modules by default GO111MODULES=on.

Invoke the go command in a directory outside of the $GOPATH/src tree, with a valid go.mod file in the current directory or any parent of it and the environment variable GO111MODULE unset (or explicitly set to auto).

Go team is planning on deprecating the $GOPATH in go1.13 and making GO111MODULES=on by default.

Alternatively this could just be left to users defining their GO111MODULE in a Makefile or build script.

[cedrickring]

So basically if there's a go.mod file, the files won't be copied to the $GOPATH and (Makefile-)commands are executed right in place?

I've never worked with Go Modules before :D

[dougnukem]

Yeah essentially go.mod indicates that the projects dependencies can be resolved by go mod which will download the pinned specific versions of the dependencies into a $GOPATH/pkg/mod/ that versions dependencies by semantic version or VCS revision e.g.

 ls -al $GOPATH/pkg/mod
 go4.org@v0.0.0-20161118210015-09d86de304dc
 go4.org@v0.0.0-20180809161055-417644f6feb5
 go4.org@v0.0.0-20181109185143-00e24f1b2599

Eventually $GOPATH/src is planned to be deprecated in go1.13.

The other option that can work in conjunction with go.mod is to use go.mod to version and lock dependencies but use the /vendor folder e.g.

# sync /vendor to match the go.mod specified dependencies
$ go mod vendor

# Build using /vendor and ignoring go.mod
$ GOFLAGS=-mod=vendor; go build ./...

So it might even make sense to have the following behavior:

1. If go.mod present

• if /vendor exists set GOFLAGS=-mod=vendor(this will use /vendor for go build and go test)
• else run with project outside $GOPATH or with GO111MODULE=on enabled to enable go modules for managing dependencies

2. else run build normally copy to $GOPATH and run go build / go test

[dougnukem]

I can put up a PR and a test repo to see if its something you want to include in this base golang action

[dougnukem]

Here's an example of using go modules: https://github.com/actions/workflow-parser/pull/30

[cedrickring]

if /vendor exists set GOFLAGS=-mod=vendor(this will use /vendor for go build and go test)

1. So this only applies to the go build && go test command?
2. When running make targets, you need to specify that by yourself?

[dougnukem]

1.So this only applies to the go build && go test command?

Yes for go build && go test it will actually apply to other go toolchain commands but those are the relevant ones.

In addition if the project is NOT using /vendor it probably makes sense to have the go build Action run with:

-mod=readonly means refuse to automatically update go.mod (mainly for CI testing).
This ensures that if changes the user make would update the go.mod (e.g. introduce a new dependency) the command will fail, this is useful to ensure that changes to code that add/remove dependencies also have corresponding go.mod changes from the user
https://go-review.googlesource.com/c/go/+/126696

2. When running make targets, you need to specify that by yourself?

Yes, if the user of the action specifies their own make targets then they'd be responsible for configuring the GOFLAGS and go build commands to run using go.mod or -mod=vendor themselves.

[dougnukem]

@cedrickring I've got a PR that adds support for go.mod go modules if present.
-#6

Also a series of other PRs to add tests and support for multiple golang versions in the repo.

[cedrickring]

Hey @dougnukem, thanks for all the PRs. I'm quite busy atm, but I'll look into them later today or tomorrow 👍

[cedrickring]

Getting this error for the go dep vendor test:
golang.org/x/text: hash of vendored tree not equal to digest in Gopkg.lock

https://github.com/cedrickring/golang-action/runs/74952504

[dougnukem]

I'll take a look

Getting this error for the go dep vendor test:
golang.org/x/text: hash of vendored tree not equal to digest in Gopkg.lock

https://github.com/cedrickring/golang-action/runs/74952504

[dougnukem]

@cedrickring hmm trying to reproduce that error local I'm unable to, is there any way to manually kick off the action run again in case it was an intermittent issue.

Also are you able to run it locally e.g. via: https://github.com/nektos/act

$ go get -u github.com/nektos/act
$ act -a "Test Go Dep Vendor"
[Lint] git clone 'https://github.com/actions/action-builder' # ref=master
[Lint] docker build -t action-builder:master /var/folders/ht/gwk63jw55_b_kpkk3jf599r40000gn/T/act/actions/action-builder/shell@master/shell
[Lint] docker run image=action-builder:master entrypoint=["make"] cmd=["lint"]
...
[Test Go Dep Vendor] docker build -t golang-action:eeb010f /Users/douglasdaniels/dev/src/github.com/cedrickring/golang-action
[Test Go Dep Vendor] docker run image=golang-action:eeb010f entrypoint=[] cmd=[]
ok  	github.com/cedrickring/golang-action/tests/projects/go_dep_vendored	0.004s
?   	github.com/cedrickring/golang-action/tests/projects/go_dep_vendored/cmd	[no test files]

[dougnukem]

I wonder if there is some weirdness validating the hash of the text package due to some line-ending differences of me running on a MacOS env vs a purely linux one, or git configuration.

Dep documentation claims its Gopkg.lock accounts for that:
https://golang.github.io/dep/docs/Gopkg.lock.html#digest

The hash digest of the contents of vendor/ for this project, after pruning rules have been applied. The digest is versioned, by way of a colon-delimited prefix; the string is of the form : . The hashing algorithm corresponding to version 1 is SHA256, as implemented in the stdlib package crypto/sha256.

There are some tweaks that differentiate the hasher apart from a naive filesystem tree hashing implementation:

Symlinks are ignored.
Line endings are normalized to LF (using an algorithm similar to git's) in order to ensure digests do not vary across platforms.

Maybe I can just disable support for vendored dep default build support and investigate that separately.