-
Notifications
You must be signed in to change notification settings - Fork 123
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
Better/less verbose error formatting? #261
Comments
Hi @carlpett , this is by design - actually made to make it easier to understand exactly what is wrong. In some cases when using registries, seeing what schema the resource is validated against is useful. Apart from the additional schema information, it seems pretty close to what it was before.. There is a JSON output, I guess if you pipe it to jq you could get a custom error message.
But I don't think I would really remove information from the output as it is now 🙇 |
Hi @yannh, |
Hey,
Since v0.6/#168 the errors on failed validations have gotten a lot more verbose/noisier. I suspect a lot of this comes from the new underlying library, but is there something we can do to support reformatting them?
Example of the same error in v0.5 vs v0.6:
ScaledObject so is invalid: For field spec.triggers.0: Additional property metricType is not allowed
vs
ScaledObject so is invalid: problem validating schema. Check JSON formatting: jsonschema: '/spec/triggers/0' does not validate with file:///var/cache/kubeconform/crds/scaledobject_v1alpha1.json#/properties/spec/properties/triggers/items/additionalProperties: additionalProperties 'metricType' not allowed
We've rolled back after complaints from internal users about it being much harder to figure out what is wrong. For such end users, the schema file location is not very helpful at all, but takes a lot of visual space. Similarly, there's a lot of error wrapping that's relevant when hacking on
kubeconform
itself.The text was updated successfully, but these errors were encountered: