-
Notifications
You must be signed in to change notification settings - Fork 419
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
applyconfiguration-gen does not respect the +groupName tag and uses the plain apiVersion #150
Comments
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
This is still an issue. /remove-lifecycle stale |
I've experienced a very similar issue https://kubernetes.slack.com/archives/CAR30FCJZ/p1692114473185959. According to the code, the group is derived either from the path or from the field of the defined |
FWIW, I got this to work if the |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
Most go code generators such as kube-openapi rely on gengo [1] to infer the annotated tags. When dealing with package annotations, gengo extracts them from the doc.go file [2]. The types defined in apis/metal3.io/v1alpha1 do have a package annotated with +groupName. However, the annotation is in the groupversion_info.go file instead. You can see comments that refer to this issue [3] [1] https://github.com/kubernetes/gengo/ [2] https://github.com/kubernetes/gengo/blob/2b36238f13e9b8aebe4c286c2ffb2fc71f4be3c5/types/types.go#L121-L126 [3] kubernetes/code-generator#150 (comment)
Most go code generators such as kube-openapi rely on gengo [1] to infer the annotated tags. When dealing with package annotations, gengo extracts them from the doc.go file [2]. The types defined in apis/metal3.io/v1alpha1 do have a package annotated with +groupName. However, the annotation is in the groupversion_info.go file instead. You can see comments that refer to this issue [3] [4] [1] https://github.com/kubernetes/gengo/ [2] https://github.com/kubernetes/gengo/blob/2b36238f13e9b8aebe4c286c2ffb2fc71f4be3c5/types/types.go#L121-L126 [3] kubernetes/code-generator#150 (comment) [4] kubernetes/code-generator#135
Most go code generators such as kube-openapi rely on gengo [1] to infer the annotated tags. When dealing with package annotations, gengo extracts them from the doc.go file [2]. The types defined in apis/metal3.io/v1alpha1 do have a package annotated with +groupName. However, the annotation is in the groupversion_info.go file instead. You can see comments that refer to this issue [3] [4] [1] https://github.com/kubernetes/gengo/ [2] https://github.com/kubernetes/gengo/blob/2b36238f13e9b8aebe4c286c2ffb2fc71f4be3c5/types/types.go#L121-L126 [3] kubernetes/code-generator#150 (comment) [4] kubernetes/code-generator#135 Signed-off-by: Marc Nuri <[email protected]>
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
So when using the Operator-SDK it generates a go file like groupversion_info.go in your main API package. This defines stuff like:
I added the genclient and k8s:openapi-gen=true, both of those are ignored by the way and need to be on every type.
But it also ignores the groupName so the applyconfiguration object ends up with
While I expect
Which I can fix with
sed
but I feel like it shouldn't really be a thing. I'm at a loss currently as to how to get it to first respect the tags on the package and then to actually include the groupName.I got my generation code from here: cert-manager/cert-manager#5383
The text was updated successfully, but these errors were encountered: