Closed apparentlymart closed 6 years ago
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.
Further breadcrumbs here suggest that this was indeed a recent regression:
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.
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/...)
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.
As initially discussed in #18344, we currently run
go generate
as part of the main build process (whatmake
runs) but due to golang/go#10249 a fresh dev environment is not ready to rungo generate
because packages have not yet been installed so thatstringer
can see them.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 rungo 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.