Add NEXTEST_SHOW_PROGRESS=none to cargoNextest

[dpc]

I noticed in my usage that nix build -L ... for craneLib.cargoNextest was producing a lot of output due to progress bar, and adding NEXTEST_SHOW_PROGRESS=none fixes it. Should crane do it by default?

[ipetkov]

Are you seeing an actual progress bar or just a list of completed tests?

IIRC it should automatically disable certain outputs (eg the progressive progress bar) when the output is not a tty but still keep some output to show progress (which can be useful to tell if something has stalled out or still moving along)

If the behavior is obviously wrong I don't mind changing the defaults, but I don't want to err to far on the side of complete silence and require callers to know how to opt out of the silence

[dpc]

Are you seeing an actual progress bar or just a list of completed tests?

I think I've seen repeating lines with the exact same test name over and over, which looked like the progress bar refreshing (delete line, redraw line) went wrong. I was running nix build -L ... in a "local CI".

IIRC it should automatically disable certain outputs

I thought so too, but clearly that was not the case so something went wrong.

I don't want to err to far on the side of complete silence and require callers to know how to opt out of the silence

NEXTEST_SHOW_PROGRESS=none disables only the progress bar, so every test still gets a line when it completes with status and timing. The output is not entirely silent or anything.

In a way, I can't imagine anyone wanting it other way. Even when running in a dev shell I find it progress bar ugly anyway:

and it looks to me like it's malfunctioning. Donno. Maybe I'm holding it wrong somehow.

[ipetkov]

Ah yes you can even see the redrawing characters show up in the logs so I'm open to setting a default value for this.

Actually setting NEXTEST_SHOW_PROGRESS=counter might be a slightly better default, it still shows (n/N) for each run (none disables it entirely) but it doesn't redraw the bar at the bottom

[ipetkov]

Thanks for the note around this, I think this should be fixed with #983 but let me know if that doesn't work!