initial opencost Helm values schema

[HMetcalfeW]

Interested in the team's feedback on adding a schema to our Helm Chart. The initial generation was relatively straightforward, but as our chart evolves, this file will require ongoing maintenance. If we think this is too much maintenance, then I'm happy to table it, but believe it can pay long-term dividends. This first iteration is lax because it lacks required fields.

The practice is fairly common in the Bitnami Charts community. There's a great blog post on the motivations behind creating a Values schema and the various checks it allows.

Requirement checks. Example: An API_KEY environment variable is set
Type validation. Example: The image tag is a string such as "1.5" and not the number 1.5
Range validation. Example: The value for a CPU utilization percentage key is between 1 and 100
Constraint Validation. Example: The pullPolicy is IfNotPresent, Always, or Never; A URL has the format http(s)://:
Since schema checks are run on all Helm commands (template, lint, upgrade, install), this helps prevent customer values from drifting too far between versions and clearly defines what values are/are not allowed.

Example Helm output using a number for clusterId
helm lint .

[ERROR] templates/: values don't meet the specifications of the schema(s) in the following chart(s):
opencost:
- at '/nameOverride': got number, want string

https://helm.sh/docs/helm/helm_lint/

[ameijer]

we like this - can we break up into schema refs to make this more readable?

[ameijer]

might want to enable strict schema, ensure we validate in CI with CI vals