"go generate" doesn't work in a fresh dev environment

[apparentlymart]

As initially discussed in #18344, we currently run go generate as part of the main build process (what make runs) but due to golang/go#10249 a fresh dev environment is not ready to run go generate because packages have not yet been installed so that stringer can see them.

$ make
==> Checking that code complies with gofmt requirements...
go generate ./...
2018/07/03 10:03:50 Generated command/internal_plugin_list.go
stringer: checking package: decoder_spec.go:4:2: could not import github.com/hashicorp/hcl2/hcldec (can't find import: "github.com/hashicorp/terraform/vendor/github.com/hashicorp/hcl2/hcldec")
config/configschema/schema.go:80: running "stringer": exit status 1
stringer: checking package: backend.go:4:2: could not import github.com/hashicorp/hcl2/hcl (can't find import: "github.com/hashicorp/terraform/vendor/github.com/hashicorp/hcl2/hcl")
configs/provisioner.go:139: running "stringer": exit status 1
stringer: checking package: diagnostics.go:7:2: could not import github.com/hashicorp/errwrap (can't find import: "github.com/hashicorp/terraform/vendor/github.com/hashicorp/errwrap")
tfdiags/diagnostic.go:11: running "stringer": exit status 1
Makefile:75: recipe for target 'generate' failed
make: *** [generate] Error 1

Normal Go development practice is for go generate to be a separate step from build, so we might choose to address this by taking the generate step out of the default make target altogether and require developers to run go generate manually if they are changing something that is subject to code generation. I believe most Go developers are accustomed to doing this anyway, but it'll probably be surprising for those who are not familiar with Go development so we may need to add some additional documentation close to the parts of the code that are subject to code generation (enums, etc) as a prompt for future maintainers.

[apparentlymart]

It seems that we're now seeing this error in Travis-CI too. Possible that it was a regression caused by a recent stringer change. Will investigate further soon.

[apparentlymart]

Further breadcrumbs here suggest that this was indeed a recent regression:

• x/tools/cmd/stringer: cannot import vendored dependencies golang/go#21387
• x/tools/cmd/stringer: can't find packages golang/go#10249 (comment)

[apparentlymart]

At the moment we're just waiting for some dust to settle on the Go side here, and then we'll see if we need to take any further action in our README and Travis-CI configurations.

Unfortunately that means that for the moment any new PR will get a Travis-CI error, so if this isn't resolved upstream soon then we'll start to investigate workarounds.

[caarlos0]

FWIW, my workaround on goreleaser:

setup:
	rm -rf $$GOPATH/src/golang.org/x/tools
	go get -u golang.org/x/tools/cmd/stringer
	go get -u golang.org/x/tools/cmd/cover
	# TODO: temporary hack for https://github.com/golang/go/issues/21387
	(cd $$GOPATH/src/golang.org/x/tools; git checkout ae8cc594552814363a7aeeb4f2825515a771fa38; go install ./cmd/stringer/... ; go install ./cmd/cover/...)

[apparentlymart]

Over in golang/go#10249 after some discussion the reverting was reverted, so we should now be back to a working state again.

From peeking at a few recent PRs I see that they are no longer failing the Travis-CI run, or at least (in some cases) now failing for more legitimate reasons.

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.