Closed kMutagene closed 2 months ago
Additionally, we could also include the full package metadata in the ValidationPackage
section/object
I prefer the nested structure personally. Doesn't really make the parsing any worse but it makes the data structure cleaner imo.
Just a reference on what i settled on implementing in #99 in this regard:
{
"Critical": {
"HasFailures": false,
"Total": 1,
"Passed": 1,
"Failed": 0,
"Errored": 0
},
"NonCritical": {
"HasFailures": false,
"Total": 1,
"Passed": 1,
"Failed": 0,
"Errored": 0
},
"ValidationPackage": {
"Name": "test",
"Version": "1.0.0",
"Summary": "A package with CQC hook.",
"Description": "A package with CQC hook. More text here.",
"HookEndpoint": "http://test.com"
}
}
With HookEndpoint
bein optional, meaning key and value can be ommitted.
Also, we should specify this format in the arc specification.
We need a summary file that aggregates information about performed validations for consumption in downstream files.
Currently, this information was identified to be needed:
boolean
integer
integer
integer
boolean
integer
integer
integer
string
string
string
Upon initial discussions, this file should be of
json
format. We could additionally create a simple json schema for this.Example
This example is the run summary of validation against the package
test 2.0.1
with 5 critical and 5 non-critical validation cases, with 1 fail each:alternatively, we could nest 3 objects
Critical
,NonCritical
, andValidationPackage
: