Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.7k
[Console] Add env var to disable direct output#53126
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
ro0NL commentedDec 18, 2023
what's the difference with SHELL_VERBOSITY=-1?https://symfony.com/doc/current/console/verbosity.html |
ro0NL commentedDec 18, 2023
Also, AFAIK the trick in docker envs et al is to use different process:https://github.com/relaxart/monolog-docker-handler/blob/master/src/DockerMonologHandler.php |
wouterj commentedDec 18, 2023
As indicated in the issue, we have some rendering that still outputs with quiet/verbosity=-1 (e.g. errors). |
| } | ||
| if (true ===$input->hasParameterOption(['--quiet','-q'],true)) { | ||
| if (true ===$input->hasParameterOption(['--quiet','-q'],true) ||$this->isDirectOutputDisabled()) { |
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 same code path can be triggered using SHELL_VERBOSITY=-1 isnt it?
https://github.com/symfony/symfony/blob/7.1/src/Symfony/Component/Console/Application.php#L919-L921
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.
Yes, this was more as a shortcut soSYMFONY_CONSOLE_OUTPUT=0 also implies verbosity -1
I would also be fine with not rendering throwables/errors whenSHELL_VERBOSITY=-1 in theApplication class if that's preferred and not considered a BC break.
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'd like to avoid SYMFONY_CONSOLE_OUTPUT vs SHELL_VERBOSITY yes :)
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 understand the BC concern, perhaps we need to reconsider what --quiet really means 😅
SHELL_VERBOSITY=-2 maybe?
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 agree that expandingSHELL_VERBOSITY modes would be better than a new env var.
SHELL_VERBOSITY=-2 maybe?
👍 and--silent maybe
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'd consider making -q really quiet
i see no reason to preserve just error output with -q (assuming error logging is setup)
relying on humans to look at output, is error prone anyway
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've submitted the alternative in a new PR (to not mix up the discussions):#53632
… including errors (wouterj)This PR was merged into the 7.2 branch.Discussion----------[Console] Add silent verbosity suppressing all output, including errors| Q | A| ------------- | ---| Branch? | 7.2| Bug fix? | no| New feature? | yes| Deprecations? | yes| Issues |Fix#52777| License | MIT<details><summary>Original PR description</summary>Alternative to#53126In Symfony 2.8, we decided to still show exceptions/errors when running a command with `--quiet` or `SHELL_VERBOSITY=-1` (#15680).Since that time, we've introduced the ConsoleLogger and 12-factor app logic. In todays landscape, it's more common to run commands that only output computer-readable text (e.g. JSON), which is ingested and displayed by services like Datadog and Kibana.Our decision from 2.8 breaks this, as the JSON is interrupted by human-readable exception output that users can't disable. At the same time, this information is duplicated as errors are always logged (and thus shown as JSON).I think we should revert the 2.8 decision, rather than adding a new "extremely quiet" verbosity mode. As far as I'm aware, this is also more consistent with normal unix commands which also don't output anything when passing `--quiet`.I don't think this warrants as a BC break, as the errors are human readable and we don't promise BC on human readable console output (afaik, we don't promise BC on any console output, but I think we should be careful when changing e.g. the JSON logging).</details>This updated PR adds a new `--silent` verbosity mode that suppresses all output, including exceptions caught by the Application.I went back and forth between simply passing `NullOutput` to the command in silent mode or not ignoring everything written to silent mode in `Output`. In the end, I've decided for the last to avoid bug reports from people silently expecting a `ConsoleOutputInterface` in their commands (e.g. for sections) without properly guarding it.The new `isSilent()` methods can be used by commands to e.g. write important messages to the logger instead of command output when running in silent mode.Commits-------57fe0bd [Console] Add silent verbosity mode suppressing all output, including errors
Uh oh!
There was an error while loading.Please reload this page.
This is useful when running in a containerized application and you've configured Monolog to write to stdout (probably using a JSON format).
Alternatively, we can also introduce a
LoggerOutputthat writes each line to an INFO log message. This can result in double messages, but has the benefit that commands don't have to be written so that useful information is logged. What do you think of this?