[Feature]: JSON Schema Validator Function #441
Assignees
Comments
|
I've been job hunting recently, so I've not been working on this as quickly as I'd like, but I was already looking into implementing this before I got laid off. The native type system is complex. So if there's merging involved, I've been experimenting with:
I like the idea of validating inputs using JSON Schema (using something like santhosh-tekuri/jsonschema, which supports a broad set of dialects). Perhaps a JSON validation function could slide between steps 2 and 3, with the option to WARN or ERROR on failure. I was trying to do something like this at a module level back in the Terraform 0.14 days when "optionals" were introduced as an experiment. I think I have some good test cases for such a feature. |
Gowiem
added a commit
to masterpointio/terraform-spacelift-automation
that referenced
this issue
Feb 3, 2025
## what - Adds the `runtime_overrides` variable + tests to check usage - ~NOTE: The new overrides test is currently failing due to what I'm calling the "Optional Type Defaults Problem". I'm posting this to share the full use-case for what we're running into so I can see if others have an elegant way to handle this problem. Below is the output of the failing tests just so it's easy to find.~ Check out the OpenTofu Slack thread linked below for full details. - [(Previously) Failing Test Output ](https://app.warp.dev/block/embed/oJjjKVlrT3uRraonoNidCB) - Introduces StackConfig schema validation using the https://registry.terraform.io/providers/bpedman/jsonschema/latest/docs - Adds `terraform-docs` as a trunk action + config for that + removes pre-commit-config ## why - `runtime_overrides` allows consumers of this child module to do logic within their root module to manage the final Stack config. This gives them additional flexibility beyond our static StackConfig configuration. ## references - [Internal Slack Thread on the tests problem](https://masterpoint.slack.com/archives/C04MUCKUDKK/p1737646084251039) - [OpenTofu Community Slack Thread on this issue](https://opentofucommunity.slack.com/archives/C05R0FD0VRU/p1737659803219399) - [Future path towards not using the jsonschema data source](northwood-labs/terraform-provider-corefunc#441 (comment)) - [jsonschema_validator data source](https://registry.terraform.io/providers/bpedman/jsonschema/latest/docs/data-sources/jsonschema_validator)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What functionality would you like to see?
My team and I have run into an issue a number of times with what I'm calling the "Optional Type Defaults Problem" (bad name). Lots of info in the OpenTofu Slack. The quick summary: when merging objects with optional fields, there can be null values that unintentionally override desired defaults. This leads to unexpected / undesired behavior in complex module configurations.
The end result of this issue is that we can't use the TF type system to do what we want and instead we're going to specify
anyas our type for complex objects in certain cases and then we'll use a JSON schema to validate the given variable value at runtime. To do this today, we're thinking about using thejsonschema_validatordata source from the jsonschema providera. However that is an old, seemingly unpopular provider and the validation is not implemented as a function.I would love to see a
str_jsonschema_validatefunction in this provider. If there is interest, I can try to put up a PR to add this.The text was updated successfully, but these errors were encountered: