You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What problem does this solve or what need does it fill?
The CI test script produces a very large volume of output (especially with --keep-going), and almost all of it is not useful: it's just tests succeeding. With automated testing this isn't really an issue (especially since, at the moment, the test scripts crash shortly after anything fails), but when running tests locally, it can be annoying.
What solution would you like?
The ability to pass a --quiet flag, e.g. cargo run -p ci -- --quiet, cargo run -p ci -- --keep-going --quiet etc. could ameliorate this considerably. The flag would mostly mean passing --quiet to the constituent tests of the script so that it suppresses the flood of success outputs.
What alternative(s) have you considered?
Manually redirecting stdout to /dev/null does an okayish job of suppressing some of the output; e.g.: cargo run -p ci -- --keepgoing > /dev/null. However, this kills all of the output from our lints, and it doesn't suppress as much as --quiet would, so it's a very imperfect solution.
The text was updated successfully, but these errors were encountered:
Follow-up from #12242
What problem does this solve or what need does it fill?
The CI test script produces a very large volume of output (especially with
--keep-going
), and almost all of it is not useful: it's just tests succeeding. With automated testing this isn't really an issue (especially since, at the moment, the test scripts crash shortly after anything fails), but when running tests locally, it can be annoying.What solution would you like?
The ability to pass a
--quiet
flag, e.g.cargo run -p ci -- --quiet
,cargo run -p ci -- --keep-going --quiet
etc. could ameliorate this considerably. The flag would mostly mean passing--quiet
to the constituent tests of the script so that it suppresses the flood of success outputs.What alternative(s) have you considered?
Manually redirecting stdout to /dev/null does an okayish job of suppressing some of the output; e.g.:
cargo run -p ci -- --keepgoing > /dev/null
. However, this kills all of the output from our lints, and it doesn't suppress as much as--quiet
would, so it's a very imperfect solution.The text was updated successfully, but these errors were encountered: