Using --additional-schema-locations doesn't seem to actually validate CRDs configuration

[B-Souty]

Hi, I tried using the --additional-schema-location to validate CRDs like HelmRelease or ServiceMonitor but I was unable to trigger an error by voluntarily misconfiguring one of those resource.

Expected Behavior

Setting a custom resource field type to something different than what is defined in the CRD schema should trigger an error when running kubeval against it.

Current Behavior

Running kubeval against a badly configured custom resource result in a PASS.

Steps to reproduce

Given the following badly configured resource bad-helmrelease.yaml:

apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
  name: demo-helmrelease
  namespace: default
spec:
  releaseName: demo-helmrelease
  chart:
    # repository key should be a string as defined in the crd schema. 
    # Here I set it to a map instead to try to trigger an error
    repository: 
      name: http://example.com
    name: demo-helmrelease
    version: 1.0.0
  helmVersion: v3
  values: {}

Using the helmrelease CRD schema located at https://github.com/ams0/kubernetes-json-schema/blob/master/master-standalone/helmrelease-helm-v1.json where the repository key is defined as follow:

"repository": {
  "description": "RepoURL is the URL of the Helm repository, e.g. `https://kubernetes-charts.storage.googleapis.com` or `https://charts.example.com`.",
  "type": "string"
},

Running kubeval against this resource result in the following output:

kubeval bad-helmrelease.yml --additional-schema-locations https://raw.githubusercontent.com/ams0/kubernetes-json-schema/master

PASS - bad-helmrelease.yml contains a valid HelmRelease (default.demo-helmrelease)

[joshuaspence]

I think this is an issue with the JSON schemas rather than Kubeval and I think that I have a solution in #47 (comment)

[B-Souty]

Indeed, using @joshuaspence repository as target to --additional-schema-locations now correctly validates crds.