-
Notifications
You must be signed in to change notification settings - Fork 66
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
Add support for JSON & YAML output types #26
Add support for JSON & YAML output types #26
Conversation
5792a68
to
44a32bc
Compare
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.
Thanks @levikobi !
Overall it looks good to me!
As discussed offline, I am good with having this one without any tests now as we need to refactor the code a bit to be more extensible and testable.
Can you make sure you open a followup issue to for this work ?
Thanks for the review @LiorLieberman ! |
Aside from one small nit, looks good to me. Thanks! /lgtm |
Since you add more tests also need to change the test target in the makefile to include cmd/ tests |
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.
Thanks @levikobi!
if len(errors) > 0 { | ||
fmt.Printf("# Encountered %d errors\n", len(errors)) | ||
for _, err := range errors { | ||
fmt.Printf("# %s", err) | ||
} | ||
} |
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.
Maybe errors should also be output in JSON/YAML form?
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.
Interesting thought. Which fields would you suggest adding to the JSON/YAML, in addition to an "errors" array? If you have an example, it would be great to see one.
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.
No strong preference what it looks like, just if a user asks for json or yaml output it seems ideal to provide that format, even if the output is just a list of errors. Though I can be convinced against this, I can't remember what kubectl does here.
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.
The default output format right now is YAML, which means that whether or not I specify an output format, I will never get a plain error message (always YAML/JSON). Personally, I can't think of any CLI tool that displays error messages in this way, especially in the Kubernetes ecosystem, but I may be wrong.
Overall, I'm not so sure about it. However, if you are up for it, then there's no problem.
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.
yeah that's fair, I guess most CLI tools don't output error messages in yaml or JSON
cmd/print.go
Outdated
case "json": | ||
return &printers.JSONPrinter{} | ||
default: | ||
return nil |
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.
Any reason not to default to yaml? What would happen if we had a nil resource printer?
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.
If I had defaulted to YAML and the users entered "i2gw print -o xml" for example, they would have still received a YAML format without any indication of what was wrong. In this way, if they don't specify anything, the default is YAML (outputFormat=""). Moreover, if they specify an incorrect format, they will receive a comprehensible error message.
Regarding your second point, I wonder if we should return an error when the output is not supported to make this function more intuitive. Or maybe just indicating in the function comment that a nil value may be returned..
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.
I wonder if we should return an error when the output is not supported to make this function more intuitive
Yeah I think that's a good idea, fine with leaving that for a follow up though.
@LiorLieberman set up presubmits for this repo, let's see if they work: /retest |
/retest |
Since we added the verify now, there are a bunch of errors from code that is already in master.
|
@LiorLieberman @robscott I've opened a new PR for pull-ingress2gateway-verify fixes at #29 |
61f3b3a
to
81ab218
Compare
81ab218
to
86d6f8a
Compare
/retest |
/lgtm |
Thanks @levikobi! /approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: levikobi, robscott The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What type of PR is this?
/kind feature
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #22
Does this PR introduce a user-facing change?: