Check if MR fields do not comply with provider CRDs schema

[Piotr1215]

Thank you for putting this together, the tool is very useful, especially that it's a CLI and can be run in a pipeline.

Are there plans on the roadmap to validate MRs for nonexistent or incorrect fields? We are very conscious about paying compositions tax and often use plain MRs for simpler, non-repeatable deployments. Having validation rules check if fields in a given MR are missing, added or incorrect would help catch errors much earlier.

[MisterMX]

@Piotr1215 can you specify more what you are expecting?

The linter already checks for patches that go to / from incorrect paths. However, it does validate fields that are hardcoded in resource's base - if that is what you want.

[Piotr1215]

The composition patches check is helpful in making sure there are no typos on the patchsets names and ensuring that the patches are applied to the resources.

What I was trying to ask for is validating the resrouces schema. Let's imagine that I have this resource in my composition (patches cut for brevity):

  resources:
  - name: storagebucket
    base:
      apiVersion: storage.gcp.upbound.io/v1beta1
      kind: Bucket
      spec:
        forProvider: 
          location: us-west1
          storageClass: STANDARD
          providerConfigRef:
            name: default
    patches:
...

In this case, the location field is required. Could the validation catch if I omit this field by accident?
Now if I would add a non-existing field by mistake, for example storageType, could the validation detect that this field is not part of the spec?

Normally this check would fail on apply, but it could be beneficial to have it as a linting step in design time.

[Mitsuwa]

Perhaps as a rule it could be possible to run something like kubeconform or kubeval with --schema-location against the found MRs schema locations, though it does require that those schemas are published in an easily digestible json somewhere. I am uncertain how upbound has catagorized these within the provider repos.

[Mitsuwa]

Another option, though I fear it'll bloat this repo quite a bit and cause more maintenance, would be to use cuelang and cue get to import the go definitions of these mr structs. Then you can use the cue golang pkg to run cue vet across the objects.