-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
feat(cli): Add silent / quiet global CLI flag #24232
Conversation
CodSpeed Performance ReportMerging #24232 will improve performances by 22.52%Comparing Summary
Benchmarks breakdown
|
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.
Hi @paulomarg
Thank you for submitting the PR. --quiet
flag makes sense, however, I am pretty sure this PR won't quite achieve the functionality you want - unfortunately, we are pretty bad at centralizing our logging and there are bunch of other places within the CLI where rogue console.log
might slip in.
If you want to do an attempt at centralized logging, we'll take it. However, that might be a lot of work and I think there is way for us to proceed with this PR - just that before we can merge it, we should at least be sure that we won't make this logging situation worse in the future. And for that we'd need to snapshot output from real commands, not the fake one. You can find the examples of how to do it in cli/src/__tests__
and migrate/src/__tests__
.
Additionally, small nitpick - I don't think there is a good reason to have both --silent
and --quiet
flag, I'd prefer we'd just keep --quiet
for now.
Thank you again for this PR and let me know if you need any help.
Hey, thanks for getting back to me! That was a good callout, I added some test that would check the actual output and it does seem like a lot of it isn't coming from the command return value (see the new snapshots), so my proposal was too shallow. I agree that the right solution would have to be centralizing all of the logging and using the flag to turn that off instead, but unfortunately I won't have the time to do that :( Thanks for taking the time to review, and I hope this PR helps whatever solution you end up implementing! I'm going to close it since it doesn't feel like it'll solve the problem. |
No worries, @paulomarg, thank you for submitting the PR anyway. It won't be able to be merged is more of our failure than yours, to be honest, so, my apologies about that. |
Closes #23192
As mentioned in the issue, there are some scenarios where we want to omit the regular message returned from a command, where the output might make it harder to spot legitimate issues, or bloats the output of some scripts.
To achieve that, this PR introduces a new global
--quiet
flag (aliased to--silent
if I understood the setup correctly 😄) that simply ignores the message returned from a command, unless that is anError
.With this, users can toggle the regular output off but still catch any errors thrown by commands so we don't accidentally hide problems. Messages logged directly by a command (assuming no normal flow messages are logged that way) are still output normally.