groupName defined in types.go is not used for fake clients
#135
Comments
|
/kind bug |
|
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
k8s-ci-robot
added
the
lifecycle/stale
|
/remove-lifecycle stale |
k8s-ci-robot
removed
the
lifecycle/stale
|
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
k8s-ci-robot
added
the
lifecycle/stale
|
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
k8s-ci-robot
added
lifecycle/rotten
|
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
|
@k8s-triage-robot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/reopen |
|
@swathinsankaran: You can't reopen an issue/PR unless you authored it or you are a collaborator. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
FWIW the |
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 <marc@marcnuri.com>
When defining multiple APIs with the same version (say
v1), the+groupNametag needs to be intypes.goinstead ofdoc.goin order to not overwrite generated types inclientset.go.However, the group name defined by
+groupNameintypes.gois not used for thefake_xxx.gofiles.This results in trying to use test clients that have the incorrect group name and needs to be manually edited.
Reproduction
I attempted a minimal-ish reproduction with this go-generator-test.
In this test,
exampleandexample2both use thev1version. Whenupdate-codegen.shis run, the code generated is mostly correct:foo.bargroup name)clientset.gogenerates the correct package names for both examplesHowever, if you look at the
fake_xxx.gofiles, the group version is incorrect. It isexampleorexample2when it should befoo.bar.Now, if
+groupNameis moved fromtypes.gotodoc.gofor each of the APIs, then this issue is fixed, but duplicate package names are generated as show here.What the fix should do
I would expect the
+groupNamedefined intypes.goto be used in the generatedfake_xxx.gofiles so that the correct group name is used.The text was updated successfully, but these errors were encountered: