Unifies output handling across all registry subcommands#1200
Unifies output handling across all registry subcommands#1200jerbly merged 14 commits intoopen-telemetry:mainfrom
Conversation
…OutputTarget in TemplateOutput and OutputKind
…output-processor
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #1200 +/- ##
=====================================
Coverage 80.2% 80.3%
=====================================
Files 109 109
Lines 8769 8830 +61
=====================================
+ Hits 7039 7092 +53
- Misses 1730 1738 +8 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
jsuereth
left a comment
There was a problem hiding this comment.
Overall looks great! Good cleanup. Two nits.
| /// Try to parse a format name (already lowercased) into a builtin format. | ||
| fn from_name(name: &str) -> Option<Self> { | ||
| match name { | ||
| "json" => Some(BuiltinFormat::Json), |
There was a problem hiding this comment.
Something I was thinking for the existing weaver-packages test script -
Should we allow JQ filter expressions when we do built-in? E.g. I have a few JQ filter expressions I'm using to only pull in rego template output and I had to create a new diagnostic template for this, which MAY have the same JSON/YAML bug we saw previously.
There was a problem hiding this comment.
Of course you could pre-process before outputting. But I guess we can include the pre-processing in the OutputProcessor? Let's do this in a subsequent PR.
As I said in the PR description, with this unification in place there's now more opportunity to standardize across subcommands including breaking changes to the CLI which would tidy up the interface. Perhaps we do this with that?
Unifies output handling across all registry subcommands. Builtin output formats (json, yaml, jsonl) are now available in
registry stats,registry diff, andregistry resolve.registry statsalso supports--templatesfor custom text output templates.No breaking changes to the CLI. There is a future opportunity to unify the CLI with common terms following this PR.
OutputProcessor, a unified output abstractionOutputTargetenum models output destinations (Stdout/Stderr/File/Directory/Mute) with ergonomic helpers:from_optional_dirandfrom_optional_fileTemplateEngineandOutputDirectivecrate-internal — external consumers go throughOutputProcessorregistry statstext format from hardcodedprintln!to a Jinja templatenumsorttemplate filter for numeric key ordering)diffJSON/YAML templates now handled by builtin serialization