Skip to content
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

Merged
merged 1 commit into from
Apr 5, 2024

Conversation

tonistiigi
Copy link
Member

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

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" {
Copy link
Member

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

Copy link
Member Author

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.

Copy link
Member Author

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.

Copy link
Member

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?

Copy link
Member

@thaJeztah thaJeztah left a 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)

@crazy-max crazy-max merged commit 5c29e6e into docker:master Apr 5, 2024
63 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants