Structured validation errors #342
Description
Validation functions return all-or-nothing errors, this makes difficult to introduce different levels of errors (as warnings/fatals), or to distinguish between types of errors (as limits-related, vs. file-structure-related).
Structured errors can be the founding of different validation modes (#313), and would allow to define warning-level validations (as the ones proposed in #318, #317, #316, #341 (comment)...).
In general it would allow to optionally disable checks per package.
The structure could be something as:
- Error level (a number or an enum like warn/error/fatal...).
- Error type (unique identifier for each error type).
- Actual wrapped error.
This structure should be serializable as JSON or similar, so these errors can be easily consumed in other languages or through APIs. Something like this was requested in #285 (comment).
They should be also easily consumable by CI jobs, so warnings can be shown in jenkins reports or github comments, as mentioned in elastic/integrations#3829 (comment).
Take into account final error messages: elastic/elastic-package#994.