Disable progress on non-capable terminals#7248
Conversation
|
FWIW personally I don't agree with removing the progress entirely. There was proposal for --progress and --ansi to replace --no-progress and --no-ansi, and that will make --progress not do anything when you explicitly ask for getting progress. I do agree with disabling it by default for the reasons listed above. |
|
Sure, we can add a way for users to force it in future if needed, I would like to wait for user feedback though to see if it's really needed. Especially when The only user feedback in that area that I saw is to force colors when output is redirected, for which we are tracking a feature request already. |
|
I would plus 1 having the progress as an option. If you have hundreds of tests, then you could visually scan GHA logs and see at which point what the current state of tests was. How many succeeded, how many failed, skipped etc. Maybe it's skill issue on my part but I found this very useful, and when I noticed (after migrating to MTP v2 and .net 10) it is gone, I immediately went looking how to bring it back. I don't like taking options away. I am open to alternative suggestions on how to read CI logs, and if I'm missing some hidden feature that I should be using instead to have pretty CI logs. Also this was merged 2 months ago, however the Microsoft docs were not updated. https://learn.microsoft.com/en-us/dotnet/core/testing/microsoft-testing-platform-terminal-output#progress Hyrum’s Law ftw. |
|
@alexaka1 If you run with |
|
I am already using the detailed output, it's nice that it tells me the what order the tests run in. But personally I would still prefer having the option for the progress. |
On every repo I migrated to MTP, I have always added
--no-progressin CI. This PR makes that a default behavior. When not using a terminal that is capable of writing the progress in place, we don't write progress altogether. IMO, it's never useful to keep writing progress every 3 seconds and always results in a messy output. We will need to also make a similar change to dotnet/sdk.Related to #7056 and other similar issues (not closing any until work is done for dotnet test).