Open osher opened 8 months ago
It would indeed be useful to override a silent: true
at the root with a silent: false
on a task level.
It would indeed be useful to override a
silent: true
at the root with asilent: false
on a task level.
+1 - I was confused that this didn't take precedence.
Lets first distinct between two users:
True, in many cases they are the same, but the bigger the team/org the higher the probability that they are not. As such they have different expectations.
User Usecase 1
As automation user I don't want to see the internals, I just want the job done. For this - the automation engineers should provide
silent: true
in the root of the taskfiles.User Usecase 2
As automation user I want an option to see "under the hood" so I can gain trust on the system or consider destructive commands before I run them
:no_entry: In this case,
--dry
does not work on levels wheresilent: true
is used If that's on the root - then it's all levels, and--dry
does nothing and yields no output.Automation Engineer Usecase 1
As an automation engineer I want to be able to reverse this setting arbitrarily as I run locally in task development / troubleshoot, so that I can ask to see what's under the hood without changing codes.
Automation Engineer Usecase 2
As an automation engineer When I run with
--dry
I expectsilent: true
to be overridden withsilent: false
and be propagated down to all levels. So that I can debug my project without gotchas:no_entry: In this case,
--dry
does not work on levels wheresilent: true
is appliedAutomation Engineer Usecase 3
As an automation engineer I would like to control silent mode using environment variables So that I don't have to provide
--silent: false
every time. e.g.TASK_SILENT_MODE
Proposed Logic
I propose that when
--silent
to be stronger thanTASK_SILENT_MODE
. So that the precedence should be, from weakest to strongestTASK_SILENT_MODE
taskfile:silent
taskfile:task.silent
taskfile:task.cmds[*].silent
-s/--silent
/-S/--no-silent
--dry-run
- implies an overpoweringsilent:false