-
Notifications
You must be signed in to change notification settings - Fork 481
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
handle json formatting for print #2374
Conversation
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
@@ -855,7 +855,9 @@ func printResult(f *controllerapi.PrintFunc, res map[string]string) error { | |||
case "subrequests.describe": | |||
return printValue(subrequests.PrintDescribe, subrequests.SubrequestsDescribeDefinition.Version, f.Format, res) | |||
default: | |||
if dt, ok := res["result.txt"]; ok { | |||
if dt, ok := res["result.json"]; ok && f.Format == "json" { |
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.
(Sorry, reading from my phone, so wasn't able to check related code easily) is f.Format here the value specified through one of the command-line flags?
If so, should the "else" condition produce an error (as we're unable to satisfy the format)?
Thinking of situations where the user may try to parse JSON output and now ending up with a different format
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.
This adds "json" handling for the default:
case of the switch where previously it was only handled by the case:
branches. If the frontend does not provide expected output that contains info about how buildx can print it then the behavior atm is not well defined. Currently, in that case it prints both the full request (with expected format) and the full result from the frontend(instead of a specific known key). Maybe it should indeed error when user specifically asked for json, but that looks outside of the scope of the current PR.
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.
Actually, looking at printValue
, for known keys if frontend says it supports it but then does not provide JSON value it just prints empty value (that would not be valid json either). So it is already inconsistent. I could make the current new branch return empty value as well but that doesn't look like something that would help the user.
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! Yes, looks like there's possibly some improvements to make to make it better defined. Very likely not a blocker for this PR though.
Should we create a tracking ticket for that effort?
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.
LGTM (at least changes look trivial, and I see @daghack also reviewed)
JSON formatting was handled by the known print names, but unclear why the default case was not handled as well if user requested JSON output.
@daghack