Closed dougnukem closed 5 years ago
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
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:
go.mod
present
/vendor
exists set GOFLAGS=-mod=vendor
(this will use /vendor for go build
and go test
)$GOPATH
or with GO111MODULE=on
enabled to enable go modules for managing dependencies$GOPATH
and run go build
/ go test
I can put up a PR and a test repo to see if its something you want to include in this base golang action
Here's an example of using go modules: https://github.com/actions/workflow-parser/pull/30
if /vendor exists set GOFLAGS=-mod=vendor(this will use /vendor for go build and go test)
go build && go test
command? make
targets, you need to specify that by yourself?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 correspondinggo.mod
changes from the user https://go-review.googlesource.com/c/go/+/126696
- 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.
@cedrickring I've got a PR that adds support for go.mod
go modules if present.
-https://github.com/cedrickring/golang-action/pull/6
Also a series of other PRs to add tests and support for multiple golang versions in the repo.
Hey @dougnukem, thanks for all the PRs. I'm quite busy atm, but I'll look into them later today or tomorrow 👍
Getting this error for the go dep vendor test:
golang.org/x/text: hash of vendored tree not equal to digest in Gopkg.lock
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
@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]
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.
Go modules is looking to be the standard tool for managing dependencies and will be built into the
go build
toolchain.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
.Go team is planning on deprecating the
$GOPATH
ingo1.13
and makingGO111MODULES=on
by default.Alternatively this could just be left to users defining their GO111MODULE in a Makefile or build script.