Closed antoninbas closed 5 years ago
We talked about this and I think we have decided, yes. This is something we want to do. @GuessWhoSamFoo @bryanl unless you object, we'll have @antoninbas draft up a PR.
Thanks a lot for the quick reply @wwitzel3. I will try to draft a PR over the weekend.
My original concern was git conflict hell. Breaking go mod is a bigger deal, so we might as well check them in.
@bryanl I'll add a CI check to make sure that the generated files were generated with the "correct" mockgen version and are up-to-date
Opened the PR for this. I confirmed that it solved the go mod tidy
issue.
Description of the problem
Currently that code (e.g.
github.com/vmware-tanzu/octant/pkg/store/fake
package) is not checked-in. This creates issues for other projects which use Go module support and usegithub.com/vmware-tanzu/octant
as a dependency, as is the case when creating plugin executables. In particular, thego mod tidy
command needs to record test dependencies in the go.mod file, which cannot succeed for octant because of the missing auto-generatedfake
packages. At best (with Go 1.12) this leads to an unstablego mod tidy
, at worstgo mod tidy
(with Go 1.13) simply fails.How to reproduce
I created a sample plugin repo (by copying the sample code under
cmd/octant-sample-plugin
). You can clone it withgit clone https://github.com/antoninbas/octant-plugin-test
.go mod tidy
fails)go mod tidy
"succeeds" but is "unstable")Notice how the subsequent invocations of
go mod tidy
still try to look for the missing auto-generated code.Additional context I am not a veteran Go programmer but I believe it is considered good practice to check-in the code generated by
go generate
(see https://blog.golang.org/generate):I did not find anything in the Go release notes for 1.13 that explains the difference in behavior between the 2 Go versions.
I am also happy to submit a patch to fix this if there is agreement that the generated code should be fixed-in.