Currently there is a circular dependency in the code generation process. Before the controller-gen and angryjet tools are run, a generated type asserted as a resource.Managed or metav1.Object will be invalid, because the methodsets that satisfy these interfaces are not yet present.
controller-gen and angryjet can't run on invalid code, so the source files that rely on these type assertions or inferences (compare.go, encode.go, decode.go) can't be put in place until after these tools have successfully run.
The code generation tool needs to break up the process of generating source files into a couple distinct stages for this to flow cleanly from a single execution:
generated/generate.go (which contains the go generate tags to run controller-gen and angryjet), and for each resource types.go and doc.go
generate the index over all resource types (which is how main.go discovers them to be registered as controllers)
Note that all these files are currently generated, this issue is simply about refactoring the code that drives code generation to reorder them and take a break to run go generate after the first step.
Currently there is a circular dependency in the code generation process. Before the
controller-gen
andangryjet
tools are run, a generated type asserted as aresource.Managed
ormetav1.Object
will be invalid, because the methodsets that satisfy these interfaces are not yet present.controller-gen
andangryjet
can't run on invalid code, so the source files that rely on these type assertions or inferences (compare.go
,encode.go
,decode.go
) can't be put in place until after these tools have successfully run.The code generation tool needs to break up the process of generating source files into a couple distinct stages for this to flow cleanly from a single execution:
generated/generate.go
(which contains thego generate
tags to runcontroller-gen
andangryjet
), and for each resourcetypes.go
anddoc.go
go generate
on the target source treecompare.go
,configure.go
,decode.go
, encode.go,
index.go`Note that all these files are currently generated, this issue is simply about refactoring the code that drives code generation to reorder them and take a break to run
go generate
after the first step.