Add output: group_error_only output mode

[jaedle]

Hey 👋

I'm still a huge fan of task and I am using it quite heavily, so thanks for your effort! 👍 👏

If my motivation or details about this proposal seem to be unclear, please feel free to ask. If we agree on the details and edge-cases, it would a pleasure to implement this myself 😎

Feature description

I would like to propose a new feature in order to make my console output less verbose in case of re-occurring tasks:

Many of my taskfiles have a lot of tasks involved for some kind of workflow.
The output of single tasks is (mostly) not relevant for me if nothing errors, but is very relevant if it does (i.e. a failing test).

In order to keep my console clean and focus on potentially important messages I would like to have the chance to drop the stdout/stderr of command, if it does not error. If it errors the whole output should be shown.

Current

> task format lint test build
output from format...
output from linter...
output from test...
output from build..

Proposal for happy execution (output swallowed)

All output is swallowed as not relevant because of no errors.

> task format lint test build
(no putput)

Proposal for execution with errors (output shown for failing task)

Let's assume that the tests are broken in this example.

> task format lint test build
output from test...
task: Failed to run task "test": exit status 1

Proposal

I would like to add a configuration parameter such as show_output which could be always (default), on_error or never.
This should not break the current behavior as the default would be always.

Example Taskfile + executions

version: '3'

silent: true

tasks:

  shows_output:
    show_output: 'always'
    cmds:
      - echo 'is always shown'

  swallows_output:
    show_output: 'on_error'
    cmds:
      - echo 'a'
      - echo 'lot of'
      - echo 'output'

  shows_output_on_error:
    show_output: 'on_error'
    cmds:
      - echo 'shows error output'
      - false

  swallows_output_even_on_error:
    show_output: 'never'
    cmds:
      - echo 'is never shown'
      - false

> task shows_output
'is always shown'

> task swallows_output
(no output)

> task shows_output_on_error
shows error output

> task swallows_output_even_on_error
(no output)

I would also prefer to have a global parameter to configure the default behavior in regard of the output like silent.

version: '3'

silent: true
show_output: 'on_error'

tasks:
...

[andreynering]

Hi @jaedle,

Some thoughts on this...

To me, the behavior you're describing is very similar to using output: group, but only printing for errors as you proposed.

https://taskfile.dev/#/usage?id=output-syntax

An additional option specific to this would kinda be incompatible with output: interleaved (the default), for example, because it redirects the output while the command is still running instead of waiting for the command to complete (so we know if it errored or not).

So, I feel that the right direction here would probably to have a variant of output: group, something like output: group_error_only (hard to give a good name to this one, needs a bit of thinking to find something better).

Does this makes sense?

[jaedle]

Hi @andreynering,

after carefully reading the documentation I think this would be a perfect fit for another output type.

If you don’t mind, I could have a look at how to implement this.

I will also try to figure out a clearer naming.

[ssbarnea]

Ability to hide success output is really desirable and probably having a new group for it would be ok.

[ghostsquad]

Why is it desirable to hide success output?

[jaedle]

Let’s assume you have a verbose build tool. When you run that tool and everything goes right, I am not interested in that output.

(I usually treat warnings as errors.)

If something goes wrong during the build I guess those logs are valuebale.

[ghostsquad]

Let’s assume you have a verbose build tool. When you run that tool and everything goes right, I am not interested in that output.

(I usually treat warnings as errors.)

If something goes wrong during the build I guess those logs are valuebale.

Thank you for the explanation. I agree.

[andreynering]

Implemented on #1022.