The multi-file validate data F1 F2 … mode (thanks for #49) is great for batching — we run it over ~2,670 files in CI. One reporting gap shows up at that scale:
Each file gets a Validating <file> header, and failing files get a Validation Issues block under it, but the final summary only says:
Validation Summary:
Files validated: 2670
Issues found in 5 file(s) (7 validation issue(s))
…without naming which files. Triaging then means scanning all 2,670 Validating / Validation Issues blocks.
Request
Enumerate the failing file paths in the summary (ideally a per-file pass/fail line). The sibling linkml-term-validator already does exactly this in multi-file mode:
✅ fileA.yaml
❌ fileB.yaml - 1 issue(s):
❌ ERROR: …
Summary: 1/2 files failed, 1 total issue(s)
Matching that — at minimum, listing the failing files in the summary — would make large-batch runs much easier to triage.
Optional
An --errors-only / --quiet flag to suppress the Validating <file> line for passing files (2,670 of them is a lot of noise) would complement this nicely.
Running 0.2.1rc1.
The multi-file
validate data F1 F2 …mode (thanks for #49) is great for batching — we run it over ~2,670 files in CI. One reporting gap shows up at that scale:Each file gets a
Validating <file>header, and failing files get aValidation Issuesblock under it, but the final summary only says:…without naming which files. Triaging then means scanning all 2,670
Validating/Validation Issuesblocks.Request
Enumerate the failing file paths in the summary (ideally a per-file pass/fail line). The sibling
linkml-term-validatoralready does exactly this in multi-file mode:Matching that — at minimum, listing the failing files in the summary — would make large-batch runs much easier to triage.
Optional
An
--errors-only/--quietflag to suppress theValidating <file>line for passing files (2,670 of them is a lot of noise) would complement this nicely.Running
0.2.1rc1.