This repository has been archived by the owner on Jan 19, 2023. It is now read-only.
Consider checking-in code generated by mockgen #427
Comments
|
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 |
antoninbas
added a commit
to antoninbas/octant
that referenced
this issue
Nov 16, 2019
Using Octant as a module in another Go project (e.g. when writing a
plugin) is currently broken. "go mod tidy" fails because it needs to
record test dependencies in the go.mod file, which is not possible for
Octant because test files refer to the generated mock packages ("fake"
packages) which are not checked-in. This change solves the issue by
checking-in the "fake" files generated by "go run build.go
generate". The change includes a CI check to ensure that mocks are
always up-to-date.
Fixes vmware-archive#427
Signed-off-by: Antonin Bas <abas@vmware.com>
antoninbas
added a commit
to antoninbas/octant
that referenced
this issue
Nov 16, 2019
Using Octant as a module in another Go project (e.g. when writing a
plugin) is currently broken. "go mod tidy" fails because it needs to
record test dependencies in the go.mod file, which is not possible for
Octant because test files refer to the generated mock packages ("fake"
packages) which are not checked-in. This change solves the issue by
checking-in the "fake" files generated by "go run build.go
generate". The change includes a CI check to ensure that mocks are
always up-to-date.
Fixes vmware-archive#427
Signed-off-by: Antonin Bas <abas@vmware.com>
antoninbas
added a commit
to antoninbas/octant
that referenced
this issue
Nov 16, 2019
Using Octant as a module in another Go project (e.g. when writing a
plugin) is currently broken. "go mod tidy" fails because it needs to
record test dependencies in the go.mod file, which is not possible for
Octant because test files refer to the generated mock packages ("fake"
packages) which are not checked-in. This change solves the issue by
checking-in the "fake" files generated by "go run build.go
generate". The change includes a CI check to ensure that mocks are
always up-to-date.
Fixes vmware-archive#427
Signed-off-by: Antonin Bas <abas@vmware.com>
antoninbas
added a commit
to antoninbas/octant
that referenced
this issue
Nov 16, 2019
Using Octant as a module in another Go project (e.g. when writing a
plugin) is currently broken. "go mod tidy" fails because it needs to
record test dependencies in the go.mod file, which is not possible for
Octant because test files refer to the generated mock packages ("fake"
packages) which are not checked-in. This change solves the issue by
checking-in the "fake" files generated by "go run build.go
generate". The change includes a CI check to ensure that mocks are
always up-to-date.
Fixes vmware-archive#427
Signed-off-by: Antonin Bas <abas@vmware.com>
antoninbas
added a commit
to antoninbas/octant
that referenced
this issue
Nov 16, 2019
Using Octant as a module in another Go project (e.g. when writing a
plugin) is currently broken. "go mod tidy" fails because it needs to
record test dependencies in the go.mod file, which is not possible for
Octant because test files refer to the generated mock packages ("fake"
packages) which are not checked-in. This change solves the issue by
checking-in the "fake" files generated by "go run build.go
generate". The change includes a CI check to ensure that mocks are
always up-to-date.
Fixes vmware-archive#427
Signed-off-by: Antonin Bas <abas@vmware.com>
antoninbas
added a commit
to antoninbas/octant
that referenced
this issue
Nov 16, 2019
Using Octant as a module in another Go project (e.g. when writing a
plugin) is currently broken. "go mod tidy" fails because it needs to
record test dependencies in the go.mod file, which is not possible for
Octant because test files refer to the generated mock packages ("fake"
packages) which are not checked-in. This change solves the issue by
checking-in the "fake" files generated by "go run build.go
generate". The change includes a CI check to ensure that mocks are
always up-to-date.
Fixes vmware-archive#427
Signed-off-by: Antonin Bas <abas@vmware.com>
antoninbas
added a commit
to antoninbas/octant
that referenced
this issue
Nov 16, 2019
Using Octant as a module in another Go project (e.g. when writing a
plugin) is currently broken. "go mod tidy" fails because it needs to
record test dependencies in the go.mod file, which is not possible for
Octant because test files refer to the generated mock packages ("fake"
packages) which are not checked-in. This change solves the issue by
checking-in the "fake" files generated by "go run build.go
generate". The change includes a CI check to ensure that mocks are
always up-to-date.
Fixes vmware-archive#427
Signed-off-by: Antonin Bas <abas@vmware.com>
|
Opened the PR for this. I confirmed that it solved the |
antoninbas
added a commit
to antoninbas/octant
that referenced
this issue
Nov 16, 2019
Using Octant as a module in another Go project (e.g. when writing a
plugin) is currently broken. "go mod tidy" fails because it needs to
record test dependencies in the go.mod file, which is not possible for
Octant because test files refer to the generated mock packages ("fake"
packages) which are not checked-in. This change solves the issue by
checking-in the "fake" files generated by "go run build.go
generate". The change includes a CI check to ensure that mocks are
always up-to-date.
Fixes vmware-archive#427
Signed-off-by: Antonin Bas <abas@vmware.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description of the problem
Currently that code (e.g.
github.com/vmware-tanzu/octant/pkg/store/fakepackage) is not checked-in. This creates issues for other projects which use Go module support and usegithub.com/vmware-tanzu/octantas a dependency, as is the case when creating plugin executables. In particular, thego mod tidycommand needs to record test dependencies in the go.mod file, which cannot succeed for octant because of the missing auto-generatedfakepackages. 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 tidyfails)go mod tidy"succeeds" but is "unstable")Notice how the subsequent invocations of
go mod tidystill 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.
The text was updated successfully, but these errors were encountered: