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

Remove or convert console output to JSON when --json is given #22

Open
wundrian opened this issue Mar 15, 2019 · 1 comment
Open

Remove or convert console output to JSON when --json is given #22

wundrian opened this issue Mar 15, 2019 · 1 comment
Assignees
Labels
api-change Change that will most likely break existing APIs and may be rolled out into a new major version enhancement New feature or request
Milestone

Comments

@wundrian
Copy link
Contributor

When working non-interactively by calling the sfcc-ci program and specifying --json, for example like in the following case:

docker run docker-registry.releng.demandware.net/ccdx/dx-sfcc-ci:1.1.4-mbickel.refresh sandbox:list --json

The output may not be entirely json, for example when the authentication renewal kicks in and prints "Authentication succeeded" messages via calls to console.info to stdout.

This requires me to parse the stdout to figure out where the JSON object begins.

Can we change this so when --json is given, output is guaranteed to be a JSON object with any non-json output redirected to stderr, if necessary?

@tobiaslohr
Copy link
Contributor

I like the idea, and this makes sense of course. Any error message put to the console out is done through console.error(..), which should land into stderr already.

Do you still expect these error messages to be present in the json string of stdout? Some commands support this already. If yes, what is the format you'd expect? E.g. any error message(s) concatenated into a single error property?

For non-error messages, how do you expect this to be present, e.g. auto-renewal message?

@tobiaslohr tobiaslohr added the enhancement New feature or request label Apr 11, 2019
@tobiaslohr tobiaslohr self-assigned this Apr 2, 2020
@tobiaslohr tobiaslohr modified the milestones: 2.5.x, 3.0.x Apr 2, 2020
@tobiaslohr tobiaslohr added the api-change Change that will most likely break existing APIs and may be rolled out into a new major version label Apr 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api-change Change that will most likely break existing APIs and may be rolled out into a new major version enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants