crd-mcp-server

Validates CRD schema changes for structural equivalence and backward compatibility against git references.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

When migrating Config Connector resources from legacy to direct reconcilers, CRD schemas can accidentally drift, breaking existing user configurations. This Skill checks whether a modified CRD remains structurally equivalent or backward compatible with its previously committed version, catching breaking changes before they merge.

Core Features & Use Cases

  • Equivalence Checking: Verifies that a changed CRD has no fields added or removed under spec and no type or CEL validation changes compared to a git reference like master.
  • Backward Compatibility Checking: Confirms no fields were removed or renamed and no incompatible type changes were introduced, while allowing safe additions.
  • Presubmit Integration: Used in CI presubmits such as dev/ci/presubmits/crd-equivalence-check to enforce KRM schema stability during reconciler migration.
  • Use Case: Before promoting a CRD during a direct reconciler migration, run the equivalence check against master to confirm the schema was not unintentionally altered.

Quick Start

Ask the assistant to run the crd-mcp-server equivalence check on your modified CRD YAML file against the master git reference from the repository root.

Frequently Asked Questions about crd-mcp-server

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

FAQPage Schema
How do I check if a CRD change is backward compatible?

Run go run ./dev/tools/crd-mcp-server compatible --file <path-to-crd.yaml> --ref master from the repository root. The compatible subcommand verifies no fields were removed or renamed and no incompatible type changes were introduced.

How to verify CRD equivalence during reconciler migration?

Use the equivalent subcommand with the CRD file path and a git reference such as master. It checks that no fields were added or removed under spec and that types and CEL validations remain unchanged.

What is the difference between the equivalent and compatible subcommands?

The equivalent subcommand requires the schema to be structurally identical with no added or removed fields, while compatible permits safe additions but forbids removals, renames, and incompatible type changes.

Does the CRD checker work outside the repository root?

No, the tool must be run from the repository root of the k8s-config-connector project. It relies on relative paths to the CRD files and the git history of the repository.

When should I use equivalence checking instead of compatibility checking?

Use equivalence checking during promotion or refactoring when the schema must remain exactly unchanged, such as migrating to direct reconcilers. Use compatibility checking when intentional additive changes are allowed but breaking changes are not.