-
-
Notifications
You must be signed in to change notification settings - Fork 7.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplify travis-ci build #5219
Simplify travis-ci build #5219
Conversation
This change avoids the need to copy the source out of the GOPATH by applying GO111MODULE=on as an environment variable. Additionally, avoids issues with parallel module downloads (see golang/go#26794 and golang/go#27372) by running 'go mod download' during the install step.
I used hugo's magefile as an example for converting one of my own projects from make, and ran into many of the same issues with travis, go modules, and mage that you experienced. I thought you might be interested in this alternative solution. |
There are no issues in with parallel builds in the current setup. This is handled in the Mage script (where it belongs). Also, are you really sure that running with |
Ah, I didn't see where you addressed the parallel build problem in the
magefile. I'll take another look. My issue was cropping up intermittently
due to collisions between go fmt and go vet fetching the same modules.
My understanding is that setting GO111MODULE to 'on' makes go use the
module behavior regardless of whether it is run in the GOPATH. I can double
check that and link to the relevant docs later tonight.
…On Sat, Sep 15, 2018, 04:05 Bjørn Erik Pedersen ***@***.***> wrote:
There are no issues in with parallel builds in the current setup. This is
handled in the Mage script (where it belongs). Also, are you really sure
that running with GO111MODULE=on is exactly the same as the existing
setup? I say this because I much prefer a correct but a bit longer Travis
script than a short variant with different behaviour.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#5219 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAD5sw-M6GSG6VzdPk6PSkkCCLSANWt4ks5ubLTjgaJpZM4WqLE_>
.
|
Yes, I have read the docs on this. Which is why this variable is also set in the |
Yes, but setting GO111MODULE in the magefile only applies when running
mage, not when fetching mage with go get prior to the build.
…On Sat, Sep 15, 2018, 18:31 Bjørn Erik Pedersen ***@***.***> wrote:
My understanding is that setting GO111MODULE to 'on' makes go use the
module behavior regardless of whether it is run in the GOPATH.
Yes, I have read the docs on this. Which is why this variable is also set
in the mage file. But I have spent a stupid amount of time testing
different variations of this, and my conclusion was that the only way to
get the correct version of mage via go get (i.e. the version in go.mod)
was to have the project live outside of GOPATH.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#5219 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAD5sz8PrYBJa23XGUBaoX5xUuWQJQzgks5ubX_dgaJpZM4WqLE_>
.
|
On the off chance that it matters, here's the output of a bash session that verifies GO111MODULE=on makes go get do the correct thing even in $GOPATH/src: # the magefile/mage change tagged v1.4.0 updated mage/main.go. We'll use the sha256sum of that file to verify we got the right one.
# no existing checkouts of magefile/mage
$ ls -l $GOPATH/src/github.com/magefile/mage
ls: cannot access '/Users/user/go/src/github.com/magefile/mage': No such file or directory
$ ls -l $GOPATH/pkg/mod/github.com/magefile/mage
ls: cannot access '/Users/user/go/pkg/mod/github.com/magefile/mage': No such file or directory
# create a test project with go.mod
$ mkdir -p $GOPATH/src/example.com/test
$ cd $GOPATH/src/example.com/test
$ cat <<EOF >go.mod
> module example.com/test
>
> require (
> github.com/magefile/mage v1.4.0
> )
> EOF
# verify GO111MODULE=auto, the default
$ export GO111MODULE=auto
$ go get -v github.com/magefile/mage
go get: warning: modules disabled by GO111MODULE=auto in GOPATH/src;
ignoring go.mod;
see 'go help modules'
github.com/magefile/mage (download)
# no entry in $GOPATH/pkg/mod
$ ls -l $GOPATH/pkg/mod/github.com/magefile/mage
ls: cannot access '/Users/user/go/pkg/mod/github.com/magefile/mage': No such file or directory
# checksum mage/main.go
$ sha256sum $GOPATH/src/github.com/magefile/mage/mage/main.go
bb2f2f7df545e64c33bf7412c10b3018a59725d6b54c315d2471c8cc194f96b5 /Users/user/go/src/github.com/magefile/mage/mage/main.go
# checkout v1.4.0 and checksum mage/main.go
$ cd $GOPATH/src/github.com/magefile/mage
$ git rev-parse --short HEAD
$ git checkout v1.4.0
Note: checking out 'v1.4.0'.
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 49bafb8... Go Modules Test (#157)
$ sha256sum $GOPATH/src/github.com/magefile/mage/mage/main.go
6d656b6dda2ddb6a86c86e64ef9f9dc08bfbe1067cd4c18ef81b577c4c19d7c9 /Users/user/go/src/github.com/magefile/mage/mage/main.go
$ cd $GOPATH/src/example.com/test
$ export GO111MODULE=on
$ go get -v github.com/magefile/mage
go: extracting github.com/magefile/mage v1.4.0
# checksum mage/main.go in module checkout
$ sha256sum $GOPATH/pkg/mod/github.com/magefile/mage\@v1.4.0/mage/main.go
6d656b6dda2ddb6a86c86e64ef9f9dc08bfbe1067cd4c18ef81b577c4c19d7c9 /Users/user/go/pkg/mod/github.com/magefile/mage@v1.4.0/mage/main.go |
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
This change avoids the need to copy the source out of the GOPATH by
applying GO111MODULE=on as an environment variable. Additionally, avoids
issues with parallel module downloads (see golang/go#26794 and
golang/go#27372) by running 'go mod download' during the install step.