mockgen stopped working after upgrading to Golang 1.13

[veqryn]

We run gomock/mockgen inside of a docker container. Previously that docker container was based on golang 1.12, but we upgrade it to 1.13 today.
After upgrading to golang 1.13, mockgen started failing out:

mockgen --package=mock_seeds --destination=/go/src/github.com/xxx/yyy/mock_seeds/mock_seeds.go github.com/xxx/yyy/seeds ExternalAPIClient,ExternalAPIServer                                        
go: github.com/xxx/zzz@v0.0.0-20190917161345-2ad29436c755: invalid version: git fetch -f https://github.com/xxx/zzz refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in /go/pkg/mod/cache/vcs/595ef178a 519bba79a7580920dc80e819bacb31e39f9842a1de283c683f92cd1: exit status 128:
     fatal: could not read Username for 'https://github.com': terminal prompts disabled

Our project has several golang modules it depends on that are private, with the obfuscated https://github.com/xxx/zzz being one of them. We use go mod vendor to commit them to the repo.

Why is mockgen running go get or git fetch or anything like that?

mockgen shouldn't be getting my source files, when they are all right there already.

What is going on, and how to solve it?

[codyoss]

I will look into this, thanks for the report

[henry-jackson]

@veqryn , did your team ever find a solution to this, or did you just stay on Go 1.12? I am experiencing the same issue you are describing

This commit may be related: 577071b

[veqryn]

Stayed on golang 1.12 for now

[minicuts]

@veqryn @henry-jackson I think this is caused by the fact that 1.13 by default enables module aware behavior Under the covers, mockgen runs go build. And since you are invoking the mockgen in a directory with go.mod the executed go build command starts resolving the module dependencies. When I try go build with 1.12, it does take vendor directory into an account by default.

As a workaround, can you add to your mockgen command flag -build_flags="-mod=vendor" ?

In general, I think there should be at least better error message provided and more output so that the user user understand what mockgen does under the covers.

May I also ask a bit more details about your use case? When do you run go mod vendor ? Would it make any sense for you to run mockgen right after you run go mod vendor and "git push" the mocks into your private repo?

[veqryn]

I believe i tried using that flag and had some problems getting it to work. I can try again this weekend and report the results.

We run go mod vendor manually on our laptops whenever we update our dependencies, which is not often.

We run mockgen whenever we update any of our many interfaces, including the ones in generated files (from protobuf definitions). This happens all the time, which is why we created a docker container image that runs both protobuf generate, go generate, and mockgen (and we do commit the results from all of that, and push them up manually later as part of normal dev workflow). It would Not make sense for us to run mockgen separately, outside of the container.

[minicuts]

@veqryn Ok makes sense, thanks for explaining.

The workaround also assumes that you run the mockgen from the directory where the vendor folder and go.mod are located.

[veqryn]

That might be why it didn't work. Our go.mod and vendor directory are both in the root folder of the project, while mockgen is being run by golang files with go generate directives in them, spread deep across the project. If I remember correctly, commands run via go generate treat the directory containing the golang file as the current directory.

[minicuts]

If you run the mockgen in the context of a module (in any subdirectory of the root directory) it should work.

[minicuts]

@veqryn any update?