-
Notifications
You must be signed in to change notification settings - Fork 180
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Enhancement] Also use values.schema.json
#90
Comments
A JSON Schema should make it simpler to provide accurate documentation possibly removing the need for the custom syntax in the values file. Maybe this can be an inspiration: https://github.com/adobe/jsonschema2md |
Hey @danrspencer I think this is a very good idea. I've never written a I would merge this if implemented as you described. I do not have the time to do it myself at the moment, however. |
I’m happy to have a go when I can find some time. I’ve never written Go but if you’re willing to field a few questions from me if I get stuck I’ll see what I can do. |
I wonder how you would display We do something like this: {
"type": "object",
"$schema": "http://json-schema.org/schema#",
"definitions": {
"probe": {
"type": "object",
"additionalProperties": true,
"properties": {
"initialDelaySeconds": {
"type": "integer"
},
"periodSeconds": {
"type": "integer"
},
"timeoutSeconds": {
"type": "integer"
},
"httpGet": {
"type": ["object", "null"]
},
"exec": {
"type": "object"
},
"tcpSocket": {
"type": ["object", "null"],
"additionalProperties": true,
"properties": {
"port": {
"type": ["string", "integer"]
}
}
}
}
},
"daemons": {
"type": "object",
"additionalProperties": true,
"properties": {
"environment": {
"type": "object"
},
"list": {
"type": "array",
"items": {
"type": "object",
"additionalProperties": true,
"properties": {
"name": {
"type": "string"
},
"args": {
"type": "array",
"items": {
"type": "string"
}
},
"command": {
"type": "array",
"items": {
"type": "string"
}
},
"resources": {
"$ref": "#/definitions/resources"
}
}
}
},
"secrets": {
"type": "object"
},
"readinessProbe": {
"$ref": "#/definitions/probe"
},
"livenessProbe": {
"$ref": "#/definitions/probe"
}
}
}
}
} Just wonder how that would be represented in Markdown in your mind. |
I think definitions should just be treated as an internal implementation detail of the schema, so they’d be included before being rendered. |
Having this would be a great improvement |
Any plans on this enhancements? |
I think that in the best case scenario, it would also allow the creation of the We could maybe import functionality from https://github.com/knechtionscoding/helm-schema-gen as it simply generates a schema. |
However, it is imperative to carefully manage the directions. Exercise caution when dealing with, for example, the already existing Nonetheless, support for schemas is undoubtedly necessary; its absence is evident. During implementation, considering guidance like that provided at https://kubeapps.dev/docs/latest/howto/basic-form-support/ could be highly valuable, as compatibility with Kubeapps would be greatly appreciated. Additionally, |
Amazing tool! Thanks for this @norwoodj and all the contributors! Just passing by to update this issue for people wanting to generate both Here's how to integrate both annotations in a single # @schema
# required: false
# @schema
# -- Override release name
nameOverride: "" Hope it helps ✌️ |
It's possible to provide a schema for a Helm chart via
values.schema.json
.The schema specifies the structure of the chart along with types and descriptions of variables.
The type field would help with properties such as lists of objects, which the documentation generation currently doesn't have a good method of rendering.
The description field in the schema would be especially useful in large charts with areas of reuse as you would be able to enter a description once when specify a definition.
If there is a schema present then validating the
values.yaml
before process eliminates a large number of edge cases to worry about.Assuming the
values.yaml
is valid then the docs should render the distinct list of fields from bothvalues.schema.json
andvalues.yaml
.If both a description in the schema is present along with a comment in the
values.yaml
then the comment should probably take precedence.The text was updated successfully, but these errors were encountered: