Configuring extension tasks

[tfrimor]

Extensions should be able to use configured tasks with extension specific settings.

Currently when using a TaskProvider with provideTasks, the task configuration can be used to change problemFinders, console behavior and such.
It is not possible to have an extension specific settings that may be changed in the configuration.

The still not supported resolveTask method in TaskProvider does not quite do the trick (see #33523) as it seems to be intended to fill out incomplete tasks.

An example of task specific settings a user may want to overwrite would for instance be the number of used cores in parallel builds or similar custom settings (for an extension that wraps different embedded compilers).

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• TaskProvider: resolveTask() never gets called (#33523)

[dbaeumer]

Basically you want a preExecute hook. If so it is a dup of #43782.

And resolveTask is not meant to change task before execution. It is meant like in other resolve cases to fill in attributes that might be incomplete

[tfrimor]

Actually I think it is more the other way around than in #43782. There it is about substituting parts of the task with values from inside the extension. I.e. replacing "${cpptools:activeConfig}" in strings for the build call.

Here I would like to end up having simple configurable tasks in the tasks.json originating from the TaskProvider, where the user may provide different values.

{
    "type": "bake",
    "target": "TheTargetName",
    "file": "PathToFileContainingTargetDescription",
    "parallelBuilds": 8,
    "adapt": "GCC"
    "problemMatcher": [
        "$gcc"
    ]
}

After creating those the user should be able to change the value of parallelBuilds and adapt to values fitting their system. The type + target + file are the real TaskDefinitions, or Task ID, while the other two are task specific settings.

The TaskProvider would then receive the configured task and return one where the Task execution is set to a computed commandLine. I must admit I currently don't understand why the Task.execution from the provided task isn't showing up in the tasks.json in the first place, but then again, if I would prefer the user to change possible values, not a complex command line.

Maybe #43782 and this version can use the same perExecute API. Receiving the configured task form above and with variable substituted like in #43782.

[dbaeumer]

This actually would need a preExecute hook since the extension providing the bake task would need to change the executed command based on the set properties.

[tfrimor]

Yes. But wasn't that also what perExecute would do? According to the comment in #43782:

Instead of having a plugable resolver service I would rather pass the task to the extension again to allow either tweaking some of the properties or to fully control the execution. This at the end opens up more use cases.

Sounds like the place where the extension could also be given the task + updated task settings to update its execution command (after the variable substitution).

[alexr00]

duplicate of #58836

[vscodebot]

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for existing issues here. See also our issue reporting guidelines.

Happy Coding!