[wip] Add support for kubebuilder v2

[xrmzju]

[xrmzju]

for now, two things should do:

• v2 does not generate doc.go, groupName should not take from doc.go
• // +genclient comment not supported in v2, should not use this to judge a export type

[ahmetb]

I encourage you to take a look at the source code.

We heavily rely on //+ comments for discovering certain things like apiGroups, optional fields etc.

If there's an alternative way we can discover these things, we can make code changes. The code is pretty straightforward, search for ExtractCommentTags ,//+ , // + etc.

Maybe there's an easy fix.

[zhenghuiwang]

The code for extracting group name is this line: https://github.com/ahmetb/gen-crd-api-reference-docs/blob/master/main.go#L190

The package comments are considered by gengo only if it appears in doc.go, https://github.com/kubernetes/gengo/blob/master/types/types.go#L120 which seems unnecessarily restrictive. kubebuilder v2 no longer generates doc.go.

Is it possible to consider type comments instead of package comments? For kubebuilder v2, some type comments contains // +groupName=...

(A temporary workaround is to manually create a doc.go which contains the // +groupName=... comment.)

[ahmetb]

Is it possible to consider type comments instead of package comments? For kubebuilder v2, some type comments contains // +groupName=...

Let's be more crisp here. Does every single type that correspond to a CRD actually have this field? (We currently inherit groupName for all types from that.) We currently have 1:1 mapping between "Go packages : groupName".

Let's first make sure these two assumptions still hold true.

[zhenghuiwang]

Is it possible to consider type comments instead of package comments? For kubebuilder v2, some type comments contains // +groupName=...

Let's be more crisp here. Does every single type that correspond to a CRD actually have this field? (We currently inherit groupName for all types from that.) We currently have 1:1 mapping between "Go packages : groupName".

Let's first make sure these two assumptions still hold true.

To correct my observation: the groupName comments appear in groupversion_info.go at package level.

Examples: https://github.com/kubeflow/kubeflow/blob/master/components/notebook-controller/api/v1/groupversion_info.go

https://github.com/kubeflow/kubeflow/blob/master/components/profile-controller/api/v1/groupversion_info.go

[ahmetb]

I am not actually sure if k8s.io/gengo/parser package can read values of consts/vars. So this is actually not useful GroupVersion = schema.GroupVersion{Group: "kubeflow.org", Version: "v1"} But as you said the // +groupName=kubeflow.org comment is still there.

I most probably will not be able to find the time to fix this so I recommend you give it a try.

It seems like we need to implement this as a "fallback" to the existing logic. Maybe you can read all packages, create a map of packages:groupNames (we get groupVersion from pkg name, e.g. /v1) and if the //+ comment is missing, try to read it from that map, and if that's missing, too, fail.

[yindia]

@ahmetb Any update on kube builder support ?

[ahmetb]

Nope, I am not actively working on this.

[yindia]

@ahmetb I think some one create a pr for the issue. https://github.com/ahmetb/gen-crd-api-reference-docs/pull/26

[Starefossen]

This does currently not work for operators made with later versions of kubebuilder.