Avoid swallowing of messages when using progress bar and not running in terminal #2829
Description
Description
When sentry-cli is run from something that's not a terminal, for example a process that redirects stdout to a file, the whole progress bar and any messages that are logged when the bar should be active are swallowed and lost.
For example, we had the following bug report getsentry/sentry-java#4766 (comment) where it was tricky (especially for the user) to determine the root cause of the missing uploaded jvm files.
Note that sentry-maven-plugin runs sentry-cli redirecting its output to a file (in this case the user had enabled a debug option, causing sentry-cli to be run with --log-level=debug) and then reads it back from there.
It turns out the reason why most their files weren't being uploaded was that they had non UTF-8 encoded sources.
When sentry-cli encounters such files, they're skipped, and a message is logged:
sentry-cli/src/utils/file_upload.rs
Line 727 in 1fd856c
The problem is that the progress bar is active while we emit those logs, and it appears that while redirecting output to a file, this causes all the output emitted to the progress bar itself and generally to stdout while the bar was active to vanish.
There are similar related issues upstream in the indicatif repo:
console-rs/indicatif#530
console-rs/indicatif#651
This seems to be a slightly different case than those above, because even messages that we emit through log::info (so, not only those emitted to the progress bar itself through pb.set_message), are swallowed.
I would propose we modify src/utils/progress.rs to handle the case of SENTRY_NO_PROGRESS_BAR differently to work around this issue.
If we're not using the progress bar (i.e. SENTRY_NO_PROGRESS_BAR=1, and we could also add a check if we're in a tty or not), we could not initialize the indicatif progress bar at all.
Additionally, we could log the strings we set with pb.set_message (either with log or println, tbd) in order to surface those as well.
I've tried using SENTRY_NO_PROGRESS_BAR=1, but the issue persists on current master when redirecting output to a file, indicating that to fix this the bar should not be constructed at all.
Here's a possible implementation of the proposal, to be refined/discussed #2830