Skip to content

handle json formatting for print#2374

Merged
crazy-max merged 1 commit intodocker:masterfrom
tonistiigi:print-json-format
Apr 5, 2024
Merged

handle json formatting for print#2374
crazy-max merged 1 commit intodocker:masterfrom
tonistiigi:print-json-format

Conversation

@tonistiigi
Copy link
Copy Markdown
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

Comment thread commands/build.go
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
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