Multiple Schema Locations

[Fathom5-Admin]

Unless I'm doing something wrong, I think that when you pass in multiple schema locations but are checking multiple manifests (e.g. helm template mychart | kubeconform ) . My assumption going in was that passing multiple schema locations., such as:

kubeconform -strict -schema-location default \
  -schema-location https://raw.githubusercontent.com/datreeio/CRDs-catalog/refs/heads/main/networking.istio.io/gateway_v1.json \
  -schema-location https://raw.githubusercontent.com/datreeio/CRDs-catalog/refs/heads/main/networking.istio.io/virtualservice_v1.json \
  -schema-location https://raw.githubusercontent.com/datreeio/CRDs-catalog/refs/heads/main/networking.istio.io/destinationrule_v1.json

Would look in all locations for the schema that matches the manifest.

Now I see all of the examples for using external schema locations seem to pass in the specific manifest and not multiple (though I may be extrapolating a bit since most, if not all, of the examples use the placeholder value of [MANIFEST], but I digress).

What I expected was that I could pass in multiple manifests, such as the result of helm template, and each CRD would be validated against the schema that matched based on apiVersion, and Kind.

Instead, after successfully using it to lint my istio gateway, as soon as I added a virtual service to my in-progress helm chart, I got this error:

stdin - VirtualService my-virtualservice is invalid: problem validating schema. Check JSON formatting: jsonschema: '/spec' does not validate with https://raw.githubusercontent.com/datreeio/CRDs-catalog/refs/heads/main/networking.istio.io/gateway_v1.json#/properties/spec/additionalProperties: additionalProperties 'gateways', 'hosts', 'tcp', 'exportTo' not allowed

Please take note that the first "extra" schema-location is for the networking.istio.io/gateway_v1.json , and the above error is occurring on the VirtualService manifest, which should have been validated against the networking.istio.io/virtualservice_v1.json schema, though the order in which schema locations are passed in may not be all that relevant.

I haven't looked at the code yet, but I assume kubeconform behavior is something along the line of "if not found in default schemas, check the other schema locations, in turn", with an assumption that the default schema-location does filtering on the apiVersion and Kind, to avoid false negatives (probably with some kind of map to make looking for matches easier).

If that's true, I think additional schema locations should be treated similarly. Or barring that, datree/CRDs-Catalog should be prepared similarly to the "first-party" default catalog, and instead of passing multiple schema URIs for individual schemas, you could just specify which catalogs you want with a new flag (kubconform -schema-catalog default -schema-catalog datree/CRDs-catalog) and leave the current -schema-location behavior as is. This would make it easier for folks with multiple well-known CRDs in their stack to use the CRD catalog that is advertised in kubconform's README.

Happy to submit a pull request along these lines, once there is an agreed upon design to move forward with.

Thanks for taking the time to read and for creating kubeconform. Love using this to aid development of manifests and helm charts!