encoding/jsonschema: support native conversion from CUE to jsonschema

[cueckoo]

Originally opened by @myitcv in cuelang/cue#929

An issue to capture cuelang/cue#663

[magick93]

Hello

As encoding/jsonschema: support native conversion from CUE to jsonschema cuelang/cue#929 is closed, does that mean there is now support for generating jsonschema?

[verdverm]

The issue was closed on the old repository and has been copied here.

I believe that it is not natively implemented based on: #663 (reply in thread)

[myitcv]

@verdverm is correct. This issue exists in order to capture the missing export capability for JSONSchema.

[codewithcheese]

@myitcv @mpvl I am interested in working on this jsonschema codec if possible. Is it correct that the openapi schema implementation could be extracted out as a jsonschema encoder? Has there been any further design work on how to implement the jsonschema codec that I should be aware about? Is the current implementation style still favored or do you have a better approach in mind?

[loewenstein]

I’d be interested to be able to round-trip jsonschema -> cue -> jsonschema natively in cue.

My use case being that Helm supports jsonschema to validate provided values, we have a Helm chart that already has a schema defined and I’d like to try out cue as the source of truth.

Hence, I’d like to cue import the schema, work on the cue file henceforth and derive a schema that the Helm chart then uses for validating user input.

[from-nibly]

I'm working on a schema registry for my company and would like to have cuelang be the source of truth but serve up jsonschema for compatibility with various services. Having this built into the cue cli would allow us to make that all happen with culang tool commands really easily.

[sdboyer]

FWIW the JSON Schema encoding package in Thema amounts to a generic CUE->JSON Schema converter - it takes OpenAPI 3.0 output (as produced by the cue stdlib openapi encoder) and transforms it to be valid JSON Schema.

There are some knotty bits we're still working out, primarily grafana/thema#99, but the logic has seen use in part of larger production code generation pipelines.

[stevehipwell]

Similar to @loewenstein I'm interested in this as part of a Helm solution. I'd like to POC a Helm plugin to treat cue as the source of truth for a Helm chart and use it to generate the YAML values and JSON schema prior to publishing.

[loewenstein]

FWIW @stevehipwell I explored the alternative of enabling native CUE support for Helm validation in helm/helm@main...loewenstein:helm:cue

I didn't proceed any further yet, as neither the Helm nor the CUE community seemed very interested.
Validation should be a pretty low hanging fruit if Helm maintainers would accept an additional explicit language for value validation.
I also started exploring replacing gotemplate as the templating language with CUE, but that's is likely to be more involved.

[stevehipwell]

@loewenstein this probably falls more into the security area. Personally I'd like to keep the DX of being able to easily modify chart values while being able to lock them down with a schema at point of publishing. For example I'd like image digests to be fixed in the schema with the repo location customisable; for debug usage the ignore schema flag could be used. Longer term helm could nativity support this but a simple plugin to run pre-publish could add functionality without needing any changes to Helm (it could also generate Artifact Hub metadata).

[konsalex]

+1 for this feature. It is really nice also for having the runtime validation in CUE, but produce assets that enable IDE autocomplete, which is where JSONschema has really good adoption.

[JuryA]

I would fully support integrating CUE directly into Helm, especially if it successfully replaces the current unmarshaller. The current state of Helm Values is disastrous, mainly due to its impracticality.

If I recall correctly, JSON Schema support is limited to Draft 7, and even then, it’s rather poor—I’ve encountered several issues that deviate from the standard. Frankly, writing JSON Schemas is extremely challenging; you’d almost need a doctorate in rocket science to master it. I believe this is the main reason it hasn’t gained much traction.

CUE could elevate Helm to an entirely new level. Schemas would finally become accessible to the average user, and CUE’s built-in features, like the ability to reference Values, would be transformative. Additionally, I can even imagine it being fully backward-compatible with the current setup. All in all, it’s clearly a win-win situation.

[JuryA]

Hey @loewenstein,

I’ve taken the initiative to draft a PR (helm/helm#13236) proposing the incorporation of CUE into Helm. I used the code from your cue branch (https://github.com/loewenstein/helm:cue) and rebased it onto the main Helm branch (https://github.com/helm/helm:main). I then modified it to process the JSON schema from the values.schema.json file using CUE for direct evaluation, replacing the outdated JSON schema validator. I tested this with the Bitnami NGINX chart (https://charts.bitnami.com/bitnami/nginx).

Before marking the PR as ready, I plan to transition the loading, validation fully, and subsequent processing of Values to CUE, ensuring full backward compatibility while enabling CUE as an option. Progress has been a bit slow since I am still getting the hang of Go, so any assistance or advice would be really helpful. Also, if anyone has feedback on the HIP draft, I am all ears. With your input, we could make Helm even better.

Btw. just FYI: I’ve mentioned you as the co-author to credit your work—hope that’s okay with you. :)