It doesn't include validators for TOML and INI, but if you're doing JSON and YAML, I would take a look at using or building upon CUE (https://cuelang.org/). It is a different take on schema definition (plus more), and is surprising terse and powerful model.
I’m one of the maintainers of the project. We’re a DevOps team and maintain a lot of different types of configuration files for all the different tools and services we support - often in the same repo. Rather than using a lot of different validators for each config format we wanted a single tool to validate all types. This enabled us to include config validation as a quality gate in our CI/CD to detect config file syntax issues early before they failed in functional testing. We open-sourced it to help other teams with similar workflows. Please let me know if you have any comments or suggestions!
I think you should make clear that you are talking about syntactic validation and not any kind of semantic one.
Totally agree, for the initial release it was not ever on our radar to do semantic validation (although I really like the idea of adding that down the road). I’ll make sure to update the README to make sure that’s clear
I feel like I missed it, but what kind of validation rules are used?
Right now we’re just checking if the file is valid json, xml, toml, etc.
Someone mentioned validation rules in another comment which is a great suggestion and something we’ll work to implement. It would also be nice to validate the configs for different tools like GitLab yaml, kubernetes config, etc. We’re still thinking through how to best implement something like that in an extensible/pluggable way.
I recently made a python library that does this. You build up specs (a json/dict), and at each layer that descends, you add a `spec_chain` entry, and build another spec for the next level. Once the specs are built, you can validate, as well as get config defaults from it.
For validating the actual values and types in config files, I've been planning to use JSON Schema to define the configuration data and then validate files against it. But I haven't seen others talk about that a lot - is it something I'm missing?
Anyone else have any suggestions for improvements or things that you'd expect to see in a tool like this? I'll take anything you've got :D All feedback so far has been added as Github issues.
I was expecting this to validate the configuration files are also valid for their use cases, not just valid JSON, TOML, etc.
If you're looking for that and Python is your jam, the library cerberus[0] is very good at it.
[0]: https://github.com/pyeve/cerberus
Cool library and great suggestion. We hadn’t needed that level of validation (originally created to be a guard against syntax errors from manual edits) but I really like validation against use cases.
Appreciate the feedback - this is exactly what I was hoping for when posting today
Cerberus seems to use some custom schema format, rather than a standard like JSON Schema?