vfsgen broken after upgrading to golang 1.13

[veqryn]

We run vfsgen 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, vfsgen started failing out:

go: github.com/ReturnPath/zzz@v0.0.0-20190917161345-2ad29436c755: invalid version: git fetch -f https://github.com/ReturnPath/zzz refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in /go/pkg/mod/cache/vcs/595ef178a519bba79a7580920dc80e819bacb31e39f9842a1de283c683f92cd1: 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 vfsgen running go get or git fetch or anything like that?

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

What is going on, and how to solve it?

[dmitshur]

vfsgen itself doesn't do go get. Are you using the vfsgendev command?

I suspect the problem is that the vfsgendev command was designed to work in GOPATH mode and no longer works in module mode in some situations. It tries to execute the code generation program in a temporary directory, which means it no longer has access to your main module. It needs to be reworked to be compatible with module mode.

If that is the problem, then I'd suggest using vfsgen yourself directly in your project rather than relying on the vfsgendev helper.

It's possible the reason you started seeing the problem when going from Go 1.12 to 1.13 is because it started to use module mode in more situations (see https://golang.org/doc/go1.13#modules). So you can also consider forcing GOPATH mode explicitly when using vfsgendev, but that is of course not a good long term solution.

[veqryn]

This was fixed by adding -mod=vendor to the run statement:
//go:generate go run -mod=vendor <etc...>