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.