-
Notifications
You must be signed in to change notification settings - Fork 136
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
JSON schema export #901
base: develop
Are you sure you want to change the base?
JSON schema export #901
Conversation
pkg/schema/type.go
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes in here all relate to #899
pkg/validations/validate.go
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes in here all relate to #899
9894894
to
1994def
Compare
probably worth rebasing on top of #904 (already merged).
even though openapi and jsonschema is similar (and more recently openapi started using json schema in some parts) i actually dont have a problem with them being two separate code paths. |
Signed-off-by: Mathias Petermann <mathias.petermann@gmail.com>
…chema Signed-off-by: Mathias Petermann <mathias.petermann@gmail.com>
1994def
to
a29ae1f
Compare
Rebased onto develop, squashed the commits, and updated the tests, to use the same ytt schemas as the openapi tests. Having played around with extracting the components from the openApi spec, into a json schema, I'm no longer sure, if it makes sense to have this as it's own export output type, even though I still like the idea to have validation in common text editors through json schema. Maybe it makes more sense to keep the code in YTT simple, and just refere to another tool/script that can extract the components from the openApi schema into a json-schema, similat to what kubeconform does to get a json schema from a kubernetes CRD using https://github.com/yannh/kubeconform/blob/master/scripts/openapi2jsonschema.py Stitching together two tools (ytt | openapi2jsonschema ) to get a json schema doesn't sound too bad. |
As described in #898 I'll make a try to integrate JSON schema export into YTT.
It's based on my previous PR #899 since it's touching the same code, and I'd like to have the validation in the json schema.
I can detangle those PRs if required, but I think #899 will merged first, and I plan to rebase and squash anyways, before converting this to a proper PR.
Right now I'm mostly looking for feedback about the structure of the code, and some hints how I could improve it.
Since openApi schema is a superset of json schema, I already tried composition of the structs, but that doesn't work with the recursive nature of
calculateProperties
.If there is some composition done, I would also argue, that the
OpenAPIDocument
should be based onJSONSchemaDocument
(and theopenAPIKeys
type renamed tojsonSchemaKeys
or similar), since that would reflect theset<->superset
nature of json schema and openApiSchema .