Hide error output when printing has been disabled

[ipeevski]

Overview

This pull request:

• Fixes a bug
• Adds a feature
• Breaks backwards compatibility
• Has tests that cover changes
• Adds or fixes documentation

Summary

Hide error output when printing has been disabled

Description

Nothing should be printed if printing is disabled.
Before, successful messages were being hidden, but error exit codes were being printed out, even if $task->silent(true);

[ipeevski]

It doesn't look like the CI failure is related to the change?!

[greg-1-anderson]

AppVeyor has started the annoying practice of providing only ONE version of PHP at a time. They recently changed their one available version from PHP 7.3 to PHP 7.4, which is what broke the appveryor tests here.

[greg-1-anderson]

@DavertMik Does this break any of your use-cases? Do you accept this is a bugfix, and not a behavior change?

[ipeevski]

I don't claim to know all the use cases of course ... but to clarify, if I want to hide all the Robo generated output (and only have my own via ->say() or old fashioned echo), there is no way to do that. I can hide output if the command was successful, but errors still show up.
If I pass in -q to the command line, it has a different side effect that ->say() calls disappear too (although echo ones still work).

What I would expect:

• call to ->silent() stops all internal Robo generated output. Including when command is run, what was it's return code, etc. It should keep visible explicit calls to ->say() etc (which it does already).
• -q I would expect does the same as the described behaviour above, but don't really mind if it keeps its current behaviour, as long as the issue in the suggested pull request is resolved.

Let me know if I can give further clarifications. My explanation is perhaps a bit convoluted.

[greg-1-anderson]

@ipeevski: I understand your use-case. I think this is a good idea for the next major release of Robo. If we want to put it in the current Robo release, we have to make sure that it does not break anyone's existing use cases. Technically this is a breaking change, unless this is a bug, as reported.

I just want the primary maintainer to weigh in and agree this is a bug.

[ipeevski]

All good. Let's see what he says.