You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now that we have KIC and KGO CRDs living in this repository, we’ll need to find a way to generate sensible documentation from the API definitions we keep here (possibly separating KGO-supported and KIC-supported types so they can still be used in KGO and KIC CRD references).
Proposed Solution
So far we’ve been generating the markdown files for KIC and KGO CRDs using github.com/elastic/crd-ref-docs. The idea I have is to use the same tool, but annotate the CR types with markers telling whether the CRD is supported by KIC/KGO or both (e.g. // +kicsupported, // +kgosupported on a CR type level). We can inspect the markers (it's a native feature of crd-ref-docs) in templates and render docs only for types that a given project supports. Templates will still live in KGO and KIC repositories.
Additional Information
Acceptance Criteria
KGO's CRDs markdown reference is rendered from kubernetes-configuration API definitions
KIC's CRDs markdown reference is rendered from kubernetes-configuration API definitions
The text was updated successfully, but these errors were encountered:
czeslavo
changed the title
Generate CRDs references for KGO and KIC separately
Generate CRDs references for KGO and KIC
Oct 3, 2024
Removing a KGO 1.4 milestone as it's been done for KGO already while for KIC it will make more sense to be done together with Kong/kubernetes-ingress-controller#6488.
Problem Statement
Now that we have KIC and KGO CRDs living in this repository, we’ll need to find a way to generate sensible documentation from the API definitions we keep here (possibly separating KGO-supported and KIC-supported types so they can still be used in KGO and KIC CRD references).
Proposed Solution
So far we’ve been generating the markdown files for KIC and KGO CRDs using github.com/elastic/crd-ref-docs. The idea I have is to use the same tool, but annotate the CR types with markers telling whether the CRD is supported by KIC/KGO or both (e.g.
// +kicsupported
,// +kgosupported
on a CR type level). We can inspect the markers (it's a native feature of crd-ref-docs) in templates and render docs only for types that a given project supports. Templates will still live in KGO and KIC repositories.Additional Information
Acceptance Criteria
kubernetes-configuration
API definitionskubernetes-configuration
API definitionsThe text was updated successfully, but these errors were encountered: