Proposal for Task API

[azatsarynnyy]

Currently, the Task extension provides the means to execute scripts or executables on the Theia backend. A Task can be described using a proposed predefined format.

I'd like to enhance the Task extension with several APIs that would offer the following features:

• allow an extension to provide its own Task format in order to add some specific properties or not to force a user to edit too complex command line, etc.;
• allow an extension to provide its own way of running/killing a Task;
• allow an extension to provide a Task programmatically to the system instead of forcing a user to describe it manually in the tasks.json.

Examples of using:

• npm extension will be able to provide a simplified format of a Task, e.g.:

{
    "label": "Start watching",
    "type": "npm",
    "script": "watch"
}

• Eclipse Che will be able to provide the properties to the Task format which are meaningful for Che command, e.g.:

{
    "label": "Build project",
    "type": "che",
    "command": "mvn clean install -f ${workspaceFolder}",
    "target": "build-machine",
    "previewURL": ""
},
{
    "label": "Show databases",
    "type": "che",
    "command": "mysql -u $MYSQL_USER -p$MYSQL_PASSWORD",
    "target": "db-machine"
},
{
    "label": "Run",
    "type": "che",
    "command": "go get -d && go run main.go",
    "target": "machine-name",
    "previewUrl": "${server.8080/tcp}"
}

• Eclipse Che will be able to provide a way of running/killing a Task, by communicating with a special json-rpc service outside of Theia server;
• npm extension will be able to read the scripts from package.json and propose it as the Tasks;
• Eclipse Che will be able to read the commands from Che workspace and propose it as the Tasks.

[azatsarynnyy]

Below are some thoughts about implementation

TaskType contribution point

Defines the possible properties for a Task.

TaskResolver contribution point

Knows how to make a Task ready to run from a description in tasks.json:

• resolves the variables in some properties of a Task;
• add the missing properties.

For example, with TaskResolver it will be possible to omit the actual command line in Task configuration in tasks.json.

TaskServer

The TaskServer is a singleton, that receives the requests for running/killing a Task (as it currently works). But instead of processing a Task directly, TaskServer delegates it to the appropriate TaskRunner depending on the type of the given Task.

TaskRunner contribution point

The TaskRunner knows how to run a Task of some type.
Possible implementations:

• ProcessTaskRunner - spawns a process on the Theia server;
• CheTaskRunner - sends a Task to some json-rpc service to execute it in a Che machine.

Handling a Task's Output

If a Task is running as PTY process using a custom TaskRunner then the TerminalWidget should be able to interact with a custom Terminal Server outside of Theia server.
It seems that this will not require major changes of Terminal extension since the TerminalWidget can be connected to any endpoint for listening to the output and it interacts with a terminal server via IBaseTerminalServer interface.

TaskProvider contribution point

The TaskProvider supplies the Tasks programmatically.
Possible implementations:

• NpmTaskProvider - reads the scripts from a package.json file;
• CheTaskProvider - reads the commands from Che workspace configuration.

[marcdumais-work]

@azatsarynnyy sounds good to me. Looking forward to trying these improvements

One background consideration is that we would eventually like to have compatibility with VS Code tasks. Based on your proposal, I think we could introduce a new task format and runner, that can interpret and run such tasks?

[azatsarynnyy]

Thank you, Marc.

we would eventually like to have compatibility with VS Code tasks

In my opinion, one of the advantages of such design is it shouldn't be difficult to ensure compatibility with the VSCode tasks' format.