Feat: Add Configurable Discovery Validation Capabilities - #37
Conversation
ClassicMMT
changed the title
8b85d87 to
ab9865a
Compare
ab9865a to
922e121
Compare
|
Some preliminary comments for now. Will give it a proper review once a few other PRs settle. |
dba5ba1 to
2a74f0b
Compare
- Add `validate_discovery_config` and `validate_discovery_config_library`. - Add `validation_error_details` to `DiscoveryConfig` and `usage_count` to `DiscoveryConfigLibrary`. - Reject configs and libraries with no YAML content, with an error that says how to fix it. - Ensure validating leaves nothing behind, even when it fails. - Let pydantic parse the nested errors payload instead of a custom validator - Add DataMasqueArgumentError
2a74f0b to
59d92d9
Compare
|
As discussed - I don't think we should be doing things like creating temporary objects in this code. Obviously the proper thing to do is introduce a dedicated server API (may not be too hard?), but failing that, the CLI could keep doing it, like it does for rulesets. If you're introducing the ArgumentError (is OK, though python's ValueError does the job perfectly well), it should be consistent everywhere across the library. Keep the validation_errors aliasing until we do the refactor, that's a useful consistency fix. Likewise the usage_count and error checking (empty id/yaml field) are good to have. The changelog says you added |
- Move temp file logic to cli - Removed DataMasqueArgumentError
|
Have moved the temp objects to the cli. |
3 participants
Required for datamasque-cli PR.