cabal-validate: Better output verbosity defaults

[9999years]

Closes #10569
Closes #10570

A new --quiet switch has been added, and some behavior in ./validate.sh (without --verbose) has been moved into --quiet mode:

• --hide-successes will be passed to test suites in --quiet mode, making it easier to track tests as they run
• Subprocess output is only captured in --quiet mode, making it easier to watch cabal build and test suite output

Some output has been hidden unless --verbose is used:

• The build plan (listing of all local packages and transitive dependencies) and the dry-run build used to produce the build plan are skipped unless --verbose is given
• The runtime configuration (e.g. the ghc and cabal-install executables being used) and tool versions are not printed unless --verbose is given

Additionally, print-config, print-tool-versions, and time-summary are no longer explicit steps, and are instead run implicitly. This means that ./validate.sh -v -s build will print the config and tool versions; they do not have to be listed explicitly.

time-summary is redundant in its current form and is removed. It may be added back in the future with more detailed output (e.g., which steps were run, how long did they take individually). (Partially closes #10571)

[Mikolaj]

Yay for removing code!

[ulysses4ever]

The description doesn't explicitly say how it affects CI output (arguably, the most visible use case of cabal-validate). First, worth reminding that CI seems to run the verbose mode. Next, attaching screenshots of some notable portions of CI output before and after the change would greatly help to evaluate the effect. But we can just wait and see, as usual...

I tried to sense the effect quickly by eyeballing parts of the output... I'm a big fan of GitHub's collapsible steps output, which are erased after this change for some steps. For instance, it's easier to locate tool versions with the old setup than the new one.

While doing this, I noticed something that may or may not worked better in the past: the headers like

═══ build (dry run) ════════════════════════════════════════════════════════════

look displaced: they are printed after the actual output of the corresponding step. I think it used to work fine (first the header, then the output). This is an issue I observe on master as well. Could it be a regression introduced by cabal-validate?..

[geekosaur]

They definitely used to come out first. I don't recall if that changed with the first version of cabal-validate.

[9999years]

They're still printed in the correct spot locally. I wonder if it's a stderr/stdout buffering issue.

[geekosaur]

Easy to check (on POSIX, at least): pipe it through cat.

[geekosaur]

Also,

1. hFlush
2. Give some thought to what happens if stdout and stderr don't go the same place.

[9999years]

OK, fixed the output ordering issue in 17ffa59. Not sure what caused it — some weird combination of subprocesses with inherited stdout/stderr handles and not explicitly setting buffering? Anyways, just setting the buffering explicitly seemed to fix it.

[geekosaur]

If you don't explicitly set buffering, it'll be line buffering on things that appear to be ttys and block buffered (8K on Linux, possibly 4K elsewhere) otherwise. Every process does its own buffering, so that will also affect things.

GNU stdbuf can be used on POSIX systems to partially (fully, if the program uses GNU libc) control subprocess buffering.