Hi, I am creating a Helm chart that comprises a dependency chart and some custom manifests. Its values.yaml defines both values for the custom manifests and some sensible default values for the dependency chart that will always be required. Imagine the following setup:
Chart.yaml
...
name: custom
dependencies:
- name: dependency-chart
version: x.x.x.
repository: ...
values.yaml
custom:
myValue: ""
dependency-chart:
someObjectValue:
propertyA: "default-value"
I would now like to generate a schema that fulfils the following criteria:
- All values for the custom manifests have
additionalProperties: false so that users are notified when they are using the wrong values.
- The schema contains the default values that I set for the dependency chart (primarily for documentation reasons, but also since some of them may be customized by users). Objects for these values should have
additionalProperties: true.
- This is necessary because when using
helm lint, the complete chart (including the dependency) will be templated. If someObjectValue also has propertyB with a default value, the linting fails because it is not contained in my schema. Consequently, the installation does not work, too.
- Ideally, the schema does not contain all values of the dependency chart. It should stay small and could easily grow to multiple 1000 lines when the dependencies schema is integrated.
The only "solution" for this that I can see right now is to manually add
# @schema
# additionalProperties: true
# @schema
to every object in the default values that I declare for the dependency chart.
Since this can be very cumbersome, it would be ideal if the setting could be defined once for the root property of the dependency (dependency-chart:) and then be recursively applied for all nested objects.
I am also open for any other solutions that let me achieve the desired schema without repeating the same annotation over and over again.
Note on including the dependency chart values in the schema
Even if I use the features from the main branch and include the schema for the complete dependency, it doesnt work because additionalProperties: false is set for all objects. For example, the values.yaml of the dependency chart defines resources as follows:
# Pod resource requests and limits
resources: {}
# requests:
# cpu: "500m"
# memory: "1024Mi"
# limits:
# cpu: "500m"
# memory: "1024Mi"
The tool then generates a schema like this:
"resources": {
"additionalProperties": false,
"type": "object"
},
As a result, I cannot set something like resources.requests.cpu.
Hi, I am creating a Helm chart that comprises a dependency chart and some custom manifests. Its
values.yamldefines both values for the custom manifests and some sensible default values for the dependency chart that will always be required. Imagine the following setup:Chart.yaml
values.yaml
I would now like to generate a schema that fulfils the following criteria:
additionalProperties: falseso that users are notified when they are using the wrong values.additionalProperties: true.helm lint, the complete chart (including the dependency) will be templated. IfsomeObjectValuealso haspropertyBwith a default value, the linting fails because it is not contained in my schema. Consequently, the installation does not work, too.The only "solution" for this that I can see right now is to manually add
to every object in the default values that I declare for the dependency chart.
Since this can be very cumbersome, it would be ideal if the setting could be defined once for the root property of the dependency (
dependency-chart:) and then be recursively applied for all nested objects.I am also open for any other solutions that let me achieve the desired schema without repeating the same annotation over and over again.
Note on including the dependency chart values in the schema
Even if I use the features from the
mainbranch and include the schema for the complete dependency, it doesnt work becauseadditionalProperties: falseis set for all objects. For example, the values.yaml of the dependency chart definesresourcesas follows:The tool then generates a schema like this:
As a result, I cannot set something like
resources.requests.cpu.