[Console] Add env var to disable direct output #53126
Conversation
|
what's the difference with SHELL_VERBOSITY=-1? https://symfony.com/doc/current/console/verbosity.html |
|
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 |
As indicated in the issue, we have some rendering that still outputs with quiet/verbosity=-1 (e.g. errors). |
| @@ -934,7 +935,7 @@ protected function configureIO(InputInterface $input, OutputInterface $output): | |||
| break; | |||
| } | |||
|
|
|||
| if (true === $input->hasParameterOption(['--quiet', '-q'], true)) { | |||
| if (true === $input->hasParameterOption(['--quiet', '-q'], true) || $this->isDirectOutputDisabled()) { | |||
There was a problem hiding this comment.
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.
Yes, this was more as a shortcut so SYMFONY_CONSOLE_OUTPUT=0 also implies verbosity -1
I would also be fine with not rendering throwables/errors when SHELL_VERBOSITY=-1 in the Application class if that's preferred and not considered a BC break.
There was a problem hiding this comment.
i'd like to avoid SYMFONY_CONSOLE_OUTPUT vs SHELL_VERBOSITY yes :)
There was a problem hiding this comment.
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.
I agree that expanding SHELL_VERBOSITY modes would be better than a new env var.
SHELL_VERBOSITY=-2 maybe?
👍 and --silent maybe
There was a problem hiding this comment.
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.
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 #53126 In 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
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?