kcc-direct-types-implementer

Scaffold KRM types and generate CRDs for Config Connector direct resources.

1.1k|367|Updated Apr 8, 2019
One-click install
npx skills add https://github.com/GoogleCloudPlatform/k8s-config-connector --skill kcc-direct-types-implementer
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: kcc-direct-types-implementer
Source: https://github.com/GoogleCloudPlatform/k8s-config-connector/tree/main/.gemini/skills/kcc-direct-types-implementer
Command: npx skills add https://github.com/GoogleCloudPlatform/k8s-config-connector --skill kcc-direct-types-implementer

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It standardizes and accelerates the creation of KRM types and CRD scaffolding for new Config Connector "direct" resources, reducing inconsistencies across generated Go types and CRD outputs.

Core Features & Use Cases

  • Generate initial KRM types for new direct resources: Produces the _types.go and generation plumbing for a new Kind by mapping it to the appropriate proto definitions.
  • Enforce CRD labeling and struct correctness: Ensures required +kubebuilder:metadata:labels are present exactly as specified and that status includes status.observedGeneration as an *int64.
  • Guarantee proto-to-KRM mapping: Verifies +kcc:proto tags on Spec and ObservedState so reconcilers and CRD generation align with GCP API semantics.
  • Register the Kind and regenerate CRDs: Ensures the new Kind is wired into register.go and that running dev/tasks/generate-crds yields the expected YAML in config/crds/resources/.

Quick Start

Implement a new direct resource by updating the versioned apis/<service>/v1alpha1/generate.sh, generating the _types.go for your Kind and proto message, registering the Kind in apis/<service>/v1alpha1/register.go, and then running dev/tasks/generate-crds to confirm the CRD YAML appears in config/crds/resources/.

Frequently Asked Questions about kcc-direct-types-implementer

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I generate KRM types for a new Config Connector direct resource?

To generate KRM types for a new Config Connector direct resource, you update the versioned generate.sh, map the new Kind to the appropriate proto message, and use go-based controllerbuilder tooling to produce the _types.go file.

How do I ensure my generated CRD has the correct kubebuilder metadata labels?

To ensure your generated CRD has the correct kubebuilder metadata labels, you must enforce exact +kubebuilder:metadata:labels tags in your Go types and validate that status includes status.observedGeneration as an *int64.

Why are my generated CRDs not landing in the config/crds/resources directory?

Generated CRDs may not land in config/crds/resources if the new Kind is not properly wired into register.go or if the dev/tasks/generate-crds task is not run after scaffolding the types.

What is the process to map GCP API proto messages to KRM Spec fields?

Mapping GCP API proto messages to KRM Spec fields requires adding +kcc:proto tags on your Spec and ObservedState structs so reconcilers and CRD generation align with the correct GCP API semantics.

Do I need to manually update register.go when adding a new direct resource?

Yes, you need to manually register the new Kind in apis/<service>/v1alpha1/register.go to ensure the controller runtime recognizes the direct resource before running the CRD generation tasks.

Can I use this scaffolding approach for resources without proto definitions?

No, this scaffolding approach requires a specific proto message mapping to generate the direct types, as the tooling relies on +kcc:proto tags to align the KRM Spec with GCP API semantics.