values.yaml annotations for regenerating values.schema.json

[mick62]

We have a few quite long values.yaml files, and they are constantly growing.

Unfortunately the current workflow supports only the initial creation of values.schema.json, but not its incremental updating.

Also many values are empty in values.yaml and are only set in accompanying values-<env>.yaml files which contain sensitive information and environment specific concrete values. Hence the type of these values is not derivable from values.yaml.

It would also be very helpful if the value constraints like e.g. enum, minimum or regex would also be reflected in values.yaml because it's cumbersome to find them in the very long values.schema.json file.

My proposal is to add (optional) comment line(s) with type annotations in values.yaml before each value line.
When generating values.schema.json from values.yaml these type annotation would then be used to refine the derived types (and to check for inconsistencies).

The syntax for the annotations should be succinct. Obvious and hence redundant information should be ommited, e.g. "type": "object" if there are child values, also derivable types like "string", "integer" of "boolean".
Also meaningful defaults should be used, e.g. all parent values should be considered as required by default. Only if the parent itself is optional this should be annotated.
In short only the manual changes necessary to the now generated values.schema.json file should be annotated.

To promote the adoption this approach it would also be helpful if there was a tool to create a new version of the existing values.yaml file by adding/updating these annotation comment lines based on the (manually edited) information in values.schema.json.

Thank you in advance

[estahn]

@mick62 I think you want to add "additionalProperties": false, to all objects, so that your CI fails if anyone adds options without creating the schema for it.

[karuppiah7890]

Hey! Sorry, I have been caught up with multiple things, so I have not been able to reply to issues / write code for this project. I'm not exactly planning on building more into the tool. This was more of a side project 😅 To be fair, I wasn't even using this at work because at the time I wrote the tool, we were still using Helm v2. I had just written the tool wondering that we could try using it / taking it for a spin when we want to migrate to Helm v3 and try using the schema feature

I would recommend forking and using the repo, I'm guessing you or others might already be doing this. I did notice a nice PR regarding annotated yaml in #10 by @k-kinzal , but then later I couldn't find any time to build on top of that PR