Feat/schema validation

[ian-howell]

What this PR does / why we need it:
When complete, this PR will close 5081.

Special notes for your reviewer:
Very much a work in progress. Any advice is greatly appreciated.

If applicable:

• this PR contains documentation
• this PR contains unit tests
• this PR has been tested for backwards compatibility

[bacongobbler]

From the conversation in #2431 and in the proposal, it was agreed that utilizing JSON schema for validation was the right way forward. Would you mind looking into that?

If you're looking for inspiration, the CNAB project utilizes JSON schema validation for the application bundle schema. Here's an example of how that schema looks.

[ian-howell]

Glad to see that this already exists and doesn't need to be built from scratch. I was getting pretty deep in the weeds with some of those changes...

The last commit should now meet the basic requirements of the spec. There's still some features to be added though.

[bacongobbler]

There's still some features to be added though.

Okay. Let me know when those features have been added and I'll take another look. Thanks!

[ian-howell]

The proposal mentions being able to generate a JSON schema from a given values file. However, Values are currently stored as map[string]interface{}, which means that the only information we can draw from a given property is its type. The types that we can determine are limited to what the json library's Unmarshal uses, which means no integers. Furthermore, if a property is null, there's no way to determine its type, and it must be omitted.

This last commit adds that functionality, but given the current limitations, the schemas it generates are very bare. In practice, a user could generate a schema, then modify it with more specific information. Is this the intention for this feature?

[ian-howell]

@bacongobbler This is just about finished, but I'm not sure where to put schema generation. Do we want to add a flag to install?

[bacongobbler]

Hey @ian-howell, thanks for the ping! I'll have a look at this tomorrow and see what we need to do to tie this one off. Thanks for taking the time to implement this!

[bacongobbler]

I'm incredibly happy with the current status of this PR. Really well done! Just one small nit about the error output, but asides that this is shaping up to be a great submission. Awesome work!

Are you planning on adding documentation so others know how to use this new functionality, or would you like some assistance getting started with that?

[ian-howell]

@adamreese Alright, this should be good to go. Let me know if there's anymore changes I need to make.

[adamreese]

Looks great! Thanks for making all the requested changes and esp the unit tests!!!

I might need to move a few things around with some of the load/render stages but this is awesome!

[bacongobbler]

LGTM as well. Thank you so much for all your hard work @ian-howell! This looks great. Can't wait to play around with it some more :)

[ghost]

I think we can leave that decision up to the chart author. [...] we could support files named values.schema.(yaml|json).

I think this would be great. If values.schema.json exists, use that. Otherwise if values.schema.yaml exists use that. Feed both through a yaml parser and there wouldn't be any issues, JSON is valid YAML after all.

Personally, I have already written all of my JSON schema files in yaml a long time ago since that's what the specification in the community roadmap had said to do and have been using that in my CI/CD workflows. I'm sure I'm not alone.