Expose shared options from sub-task to CLI flags

[rliebz]

Currently, a shared option is only exposed if the task that is directly invoked requires that option. While task-specific options can be set on the sub-task, there is no way to allow a shared option to be configurable from the parent task unless the parent task happens to use it.

For example, for the following config file, while single and double are configurable, mytask is not:

options:
  foo:
    default: hello

tasks:
  single:
    run: echo ${foo}
  double:
    run: echo ${foo} ${foo}
  mytask:
    run:
      - task: single
      - task: double

To preserve the ability to dynamically call sub-tasks through interpolation, it is not possible to know what sub-task shared options will be needed for a task when help documentation is generated.

One possible solution is to allow tasks to list shared options that should be exposed, most likely using one of these syntaxes:

options:
  foo:
    default: hello

tasks:
  syntax-a:
    options:
      foo: ~

  syntax-b:
    expose: foo  # takes a string or list

[smyrman]

Would it make sense to instead list all shared options in the global options list always?

[rliebz]

That's a good question.

The way it currently works is that global options are attached to the tusk command, while task-specific options are attached to their respective sub-commands.

For the following tusk.yml:

tasks:
  foo:
    options:
      bar: {}
    run: echo "${foo}"

The --bar flag is only accepted after the foo command name:

# valid
tusk foo --bar

# invalid
tusk --bar foo

And the shared options at the top work exactly the same as the task-specific options defined in the task in terms of CLI accessibility.

This allows tusk to keep the separation between tusk-specific configurations from task-specific configurations, so something like tusk --verbose foo and tusk foo --verbose can have completely different meanings. So I don't think it would make sense to group the shared options with global options, as their usage is different.

I'd also be hesitant to display it in the task-specific section because it could lead to confusing help messaging. For example, let's say there's a --fast flag shared between test and lint tasks, which is something I've done before. I wouldn't want it to pop up when running tusk build --help because there may not be such a thing as a "fast" build.

Is this issue a limitation you've run into? It's a use case I haven't hit in my own personal experience, but I probably knock out proper support in the next couple weeks if it would be useful on your end.

[smyrman]

The --bar flag is only accepted after the foo command name:

I get that, and I get that it's also good to leave a space where tusk can add new options without risking name conflicts with potential tusk-file shared options. If shared options where to appear before the task, then such conflicts must be handled, e.g. by letting the tuskfile options override the tusk ones.

I guess the design you describe in the issue description is perhaps still the best choice. It does mean tusk users can't define global options, and perhaps that's OK.

Is this issue a limitation you've run into? It's a use case I haven't hit in my own personal experience, but I probably knock out proper support in the next couple weeks if it would be useful on your end.

It's not a priority for us.

I did hit a case where I wanted to use shared options, and would want the help text to be displayed. However, with tusks excellent support of arguments, when statements and more, it was easy enough to redesign so that shared options where not needed.

E.g. for multiple deploy targets, use tusk deploy --server-dry-run dev over tusk deploy-dev --server-dry-run.