Hi,
A few quick comments.
There is a there is fair amount of flexibility to adjust the default
behavior for the go tooling in terms of when it updates `go.mod`, when it
is allowed to reach out to the network, when it uses the vendor directory,
etc.
In your case, you could consider something like setting the environment
variable `GOFLAGS=-mod=readonly` in CI if you want the go tooling to fail
if it would have otherwise implicitly wanted to update go.mod.
But that said, it really depends on what you want the behavior to be.
I tried to pull together a consolidated list of some related useful knobs
here:
https://github.com/thepudds/go-module-knobs/blob/master/README.md
You might want to skim that list, and then think about what you want the
behavior to be, and maybe some set of options there give you the exact
behavior you want.
Also, you probably should run `go mod tidy` (e.g., before publishing a
release, or perhaps before pushing a commit, or at least run it once). One
of the reasons `go mod tidy` exists is to ensure your current go.mod
reflects all possible build tags/OS/architecture combinations. (In
contrast, other commands like `go build` and `go test` only update go.mod
based on the current build invocation's tags/OS/architecture, as far as I
understand it). This is covered in a bit more detail here, including links
to related discussion:
https://github.com/golang/go/wiki/Modules#how-to-prepare-for-a-release
--PJ
On Friday, August 31, 2018 at 6:12:10 AM UTC-4, distributed wrote:
>
> Consider the following scenario. I commit a version of my project and I'm
> happy with the dependencies and their versions that are listed in my go.mod
> file. I push my code to the central repo and the CI starts to build the
> project with go get or go install. Because the CI builds for a GOOS/GOARCH
> pair that I did not try On My Machine, the list of .go files to be built
> changes. One of the newly added files has a dependency on a module that is
> not yet recorded in the go.mod file. go get/install promptly adds the
> dependency and fetches it from the internet.
>
> As a result, I get a binary that is built with dependencies that I don't
> know about, the versions of the dependencies being whatever was freshest
> that day.
>
> How do I prevent this situation? I do not want to forbid go get/install to
> fetch modules from the internet with GOPROXY. I'm fine that go get/install
> fetches the dependencies with versions/hashes recorded in go.mod and
> go.sum. I would only like for the build to fail if there are missing
> dependencies.
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
