-
Notifications
You must be signed in to change notification settings - Fork 0
Add json output format to check #24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: martinemde/kkpvkpnwpymy
Are you sure you want to change the base?
Conversation
217bb95 to
ef59b76
Compare
572249d to
270ac28
Compare
ivy
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me outside of a design detail: I think we should exit with a non-zero status code when there are violations.
Also suggested a doc comment to point readers/agents to the JSON schema. Love that you added a test that validates against it! 💜
| @@ -0,0 +1,104 @@ | |||
| use itertools::chain; | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| use itertools::chain; | |
| //! JSON output formatter for `pks check -o json`. | |
| //! | |
| //! Serializes check results (violations, stale TODOs, and summary) to JSON. | |
| //! See `schema/check-output.json` for the JSON Schema specification. | |
| use itertools::chain; |
tests/check_test.rs
Outdated
| .arg("-o") | ||
| .arg("json") | ||
| .assert() | ||
| .success() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| .success() | |
| .failure() |
tests/check_test.rs
Outdated
| .arg("-o") | ||
| .arg("json") | ||
| .assert() | ||
| .success() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| .success() | |
| .failure() |
| csv::write_csv(&result, std::io::stdout())?; | ||
| } | ||
| OutputFormat::JSON => { | ||
| json::write_json(&result, std::io::stdout())?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should exit with a non-zero status when there are violations:
| json::write_json(&result, std::io::stdout())?; | |
| json::write_json(&result, std::io::stdout())?; | |
| if result.has_violations() { | |
| std::process::exit(1); | |
| } |
I wonder if we should use a different code versus a runtime error? This way, callers don't have to differentiate "runtime error as plain text" versus "violations presented as JSON".
Validate against the included schema for check json output Co-authored-by: Ivy Evans <ivy.evans@gusto.com>
ef59b76 to
165a8da
Compare
This follows the convention used by linters like eslint, rubocop, and shellcheck. Builds on clap's existing behavior. All output formats (packwerk, json, csv) behave consistently: - Exit 0 when no violations - Exit 1 when violations found - Exit 2 on internal errors
270ac28 to
b722534
Compare
This change adds a json output option and provides a schema to describe the output format. The goal is to be able to programmatically parse the output of
pks checkfor other tools like danger.We decided to split the idea of a stale todo from the idea of a violation, since even though they talk about the same idea, the have different meanings.
pks update. It's a lint warning.