build: pass mod vendoring flag on newer versions of go #2142
Conversation
|
BTW the use of modules is super nifty and with its use, plus this, I can now remove a bunch of golang hacks from my distro packaging. Thanks! |
|
Ok -- this is entirely magical, everything errors out with "build flag -mod=vendor only valid when using modules" -- but it is using modules??? And it works on my machine and not in travis. |
When go autodetects that it is being run as a go mod, and that there is a vendor directory, it will still try to redownload all sources over the network, unless you use -mod=vendor to tell it to use that. Additionally, when using -mod=vendor the compiler will nicely avoid messing with $GOPATH at all, since it can operate in a completely self-contained manner. Take advantage of this, when the detected go version is at least 1.11 (when the -mod flag was introduced).
|
OK -- that (temporary commit adding bash -x debugging) mostly just told me what I already knew... But local testing helped me figure out something else, which is that It seems that Travis' language support will clone the repository to /home/travis/gopath/src/github.com/github/hub, at which point this fails. Forcing -mod=vendor for a build in which you are Thoughts on fixing this? |
|
@eli-schwartz Thanks for digging into! Maybe we can clear GOPATH before running the build script in Travis? That way, even if the repo was initially cloned to GOPATH, with the environment variable being unset, it might cease to interfere with the module-based approach. You are welcome to tweak |
The go compiler doesn't like it when you mix the two, and Travis CI does exactly that. Take advantage of the opportunity to disable it everywhere else as well.
|
I made that change in the Makefile itself. CI is now green. |
|
Thank you! 🙇 |
When go autodetects that it is being run as a go mod, and that there is a vendor directory, it will still try to redownload all sources over the network, unless you use -mod=vendor to tell it to use that. Additionally, when using -mod=vendor the compiler will nicely avoid messing with $GOPATH at all, since it can operate in a completely self-contained manner.
Take advantage of this, when the detected go version is at least 1.11 (when the -mod flag was introduced).