Generating JSON Schema when CRDSs change

[kakabisht]

Creating a new JSON Schema whenever the CRDs are modified. For more info, refer to #1962

[olblak]

This version of go is a bit outdated

[olblak]

If interested, I could help contribute to a Updatecli manifest.
Here is an example of the manifest that I am using on Updatecli
https://github.com/updatecli/website/blob/master/updatecli/updatecli.d/jsonschema.yaml

It opens PR like https://github.com/updatecli/website/

In this case it would be a bit different as we would need to use a second scm to execute the target from

https://github.com/rancher/fleet

[p-se]

I would like to propose a different process for updating. Instead of checking the changes made to CRDs when a PR has been merged, we can generate the JSON schema alongside the re-generation/update of the CRDs.

When a developer does changes to the Go structs we use for CRDs, the CRDs need to be regenerated (locally) and accompany the other changes in the PR of the developer. When could regenerate the JSON schemas alongside the regeneration of the CRDs, so that they will always be in sync with each other and also part of the PR that introduces the change. For that the generation of the schemas would need to happen when we call go generate. What happens when we call go generate is defined in generate.go.

That way all the changes would be part of the PR of the developer and CRDs and JSON schema would always be in sync.

That said, it might make sense to extract the JSON schema from the CRDs. Apparently they are contained in the CRDs. I'm worried that some comments that are used for the generation of the CRDs (and the JSON schema that are part of it) might not be picked up if we generate the JSON schemas separately from the same structs. This would also reduce our dependence on another library.

The other thing I noticed is that we might want to have separate JSON schemas for each CRD. JSON schemas are apparently most often mapped to file names. At least that's the case for how they are submitted to https://www.schemastore.org/.

Example from the front page:

{
  "name": "bower.json",
  "description": "Bower package description file",
  "fileMatch": [ "bower.json", ".bower.json" ],
  "url": "https://www.schemastore.org/bower.json"
}