crd-mapper-fuzzer-existing-type

Generates direct KRM Go types for existing CRDs while preserving strict schema compatibility.

1.1k|377|Updated Apr 8, 2019
One-click install
npx skills add https://github.com/GoogleCloudPlatform/k8s-config-connector --skill crd-mapper-fuzzer-existing-type
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: crd-mapper-fuzzer-existing-type
Source: https://github.com/GoogleCloudPlatform/k8s-config-connector/tree/main/.gemini/skills/crd-mapper-fuzzer-existing-type
Command: npx skills add https://github.com/GoogleCloudPlatform/k8s-config-connector --skill crd-mapper-fuzzer-existing-type

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Transitioning an existing Config Connector resource from Terraform or DCL to a direct controller requires generating KRM Go types and proto mappers without changing the published CRD schema, which is error-prone when done manually.

Core Features & Use Cases

  • Strict Schema Compatibility: Enforces rules so generated types produce a CRD identical to the baseline, verified with dev/tasks/diff-crds.
  • Code Generation Workflow: Standardizes generate.sh configuration for generate-types and generate-mapper with --multiversion and --include-skipped-output flags.
  • Mapper & Fuzzer Guidance: Covers hand-coded mappers for type mismatches, canonical reference types, and type-safe round-trip fuzzer helpers.
  • Use Case: When migrating ComputeAutoscaler to a direct controller, follow this workflow to generate types, hand-code slice-to-map mappers, register a fuzzer, and confirm diff-crds output is empty before opening a PR.

Quick Start

Ask the assistant to generate direct KRM types for an existing Config Connector resource such as ComputeFirewall while keeping the CRD schema unchanged.

Frequently Asked Questions about crd-mapper-fuzzer-existing-type

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

FAQPage Schema
How do I migrate an existing Config Connector resource to a direct controller?

Configure generate.sh to run generate-types per version and generate-mapper once with --multiversion, then define KRM Go types matching the baseline CRD exactly. Verify with dev/tasks/diff-crds that the schema diff is empty before running make ready-pr.

How do I keep the CRD schema unchanged when generating KRM types?

Do not add or remove fields such as spec.projectRef or status.externalRef unless present in the baseline CRD. Use pointers with +required for nested structs, reuse canonical reference types, and confirm dev/tasks/diff-crds output is empty.

Why does generate-mapper fail with int32 vs int64 type mismatches?

Proto fields typed int32 may not match KRM int64 fields, causing assignment compile errors. Prefer converting the KRM Go field to int64, which is backward compatible, or hand-code FromProto and ToProto functions in a mappers.go file.

When should I write a round-trip fuzzer for a KRM resource?

Fuzzers are not required in the first type-definition step for brownfield resources; they are added later when writing controller reconciliation logic. Register them with fuzztesting.RegisterKRMFuzzer using type-safe helpers like SpecField and StatusField.

What file name should the KRM types file use?

Name the types file after the lowercase proto message name, such as instance_types.go, not the KRM Kind name. Renaming it to match the Kind causes generator panics and duplicate file generation.