Implement stdout output customization attribute for Command objects

[deepbrook]

Description

I've found myself writing a lot of echo "<explanation of what next cmd does> commands with the silent: true property set, whenever I'm writing tasks for my users.

Let's pretend we want to supply a task that creates a file given via CLI_ARGS, without disclosing to our users what magic we used to do so (because of reasons). Currently, I would have to write something like this:

version: 3
tasks:
  create-file:
    cmds:
      - cmd: echo "Creating requested file at {{ .CLI_ARGS }}..."
        silent: true
      - cmd: touch {{ .CLI_ARGS }}
        silent: true
      - cmd: echo "done!"
        silent: true

output:

> task create-file -- foo.txt
Creating requested file at foo.txt...
done!

This bloats the task, and makes it tedious to write and parse.

My request would be a new echo field, which would implicitly set silent: true on the command object, and print the echo field's value instead when it's run. Also, allowing it to be the only field set would do away
with all the { cmd: "echo <msg>", "silent": true} constructs:

version: 3
tasks:
  create-file:
    cmds:
      - echo : Creating requested file at {{ .CLI_ARGS }}...
        cmd: touch {{ .CLI_ARGS }}
      - echo: done!

The output should be identical:

> task create-file -- foo.txt
Creating requested file at foo.txt...
done!

In summary:

Add a new field echo to the command object:

• When set to a non-empty string, its value is printed to stdout and the object's silent property implicitly set to true
• When no cmd or defer attribute is set, the command should behave identical to { cmd: "echo <msg>", "silent": true}

[timrulebosch]

Can't you do this:

version: 3
tasks:
  create-file:
    cmds:
      - cmd: > 
          echo "Creating requested file at {{ .CLI_ARGS }}..."
          touch {{ .CLI_ARGS }}
          echo "done!"
        silent: true

[deepbrook]

Ha. Yeeeah. I guess i could. 😅

I prefer my cmds to be one liners.

Your solution does away with the echo elements/ silent:true lines in the example, but having a builtin
Option to mask output instead of just hiding it is preferable imo.

For example, you can't use the above when calling other tasks, unless you call it in the multiline cmd field, which loses the vars contexts. (Yes, those called tasks could take over the echo'ing of feedback - but depending on the modularity of the task it might not be feasible or not what the user needs/wants).

[deepbrook]

Howeverrrr....

I just discovered that there's a silent field on the root, making all cmds disable output by default?

That'd still require a - cmd: echo <msg> entry, but that would be a feasible approach for that, if you don't need the output of all other cmds.

So, the use-case as such is:

• We want to print a message (task progress update, debug msg, whatever) to stdout instead of the stdout of a specific cmd or task invocation in tasks:task:cmds.
  • We want to still be able to see other cmds' outputs (setting silent: true on the root isn't an option)
  • We do not want to or cannot update the invoked task/command to print the above message for us

Arguably not the most common case for casual users of task.

[trulede]

You might get ideas from the existing grouping:
https://taskfile.dev/docs/guide#output-syntax

Otherwise, you might redirect your message echo's to a file, and then tail that file. That is a common case, simple. There are also nice logging frameworks for more advanced use cases.

A logging interface (#2384 ) has more potential ... but you would have to wait for someone to implement it to meet your requirements.

[trulede]

@deepbrook You seem to have a logging use case here, perhaps specialised, perhaps not. I suggest that you take a look a PR #2617 which offers a TASK log that includes both stdout and stderr of each command. From that JSON output you can easily implement some kind of log processor to produce a specific output exactly to your needs.

Alternatively, develop your taskfiles with a logging CLI tool (or simple cat/tail) to get your specialised output.

I think the PR #2617 would be particularly interesting, you could run task and redirect the output to a log processor that does the formatting you want, based on the JSON logs (especially the TASK logs which a structured).