Che commands binding for multi-root workspaces

[RomanNikitenko]

Current behavior

Configurations are exported from the devfile to the corresponding config file (tasks.json or launch.json) in the /workspaceFolder/.theia directory.

I think that actually che tasks at the moment are Global tasks.

For example, you have a devfile with two projects theia and che-theia and commands to build these projects (theia:build and che-theia:build tasks).
Both commands are available for running independently what workspace folder you open:

• /projects is a workspace folder: theia:build and che-theia:build tasks are available for running
• /theia is a workspace folder: theia:build and che-theia:build tasks are still available for running
• che-theia is a workspace folder: theia:build and che-theia:build tasks are still available for running

Please see more details here

But why according to our strategy theia:build and che-theia:build tasks are global?
Maybe it make sense that one of them should belongs to theia project and another one to che-theia project. At the same time user can have global task build like:

        {
            "type": "che",
            "label": "build",
            "command": "yarn",
            "target": {
                "workingDir": "${workspaceFolder}",
                "component": "che-dev"
            }
        },

New behavior

According to the doc https://www.eclipse.org/che/docs/che-7/defining-custom-commands-for-che-theia/ there are the following types of commands:

• exec
• vscode-task
• vscode-launch

Within current issue I would like to discuss how we should bind Che commands, especially taken into account that:

• we are going to support multi-root workspaces
• we are moving Che commands with type exec on user level (tasks configurations become truly Global)
• AFAIK launch configurations are going to live in the config file of /workspaceFolder/.theia directory

[RomanNikitenko]

btw: my first idea was described here #15540.

Now we have ability to define Che tasks as Global tasks on user level and we can reconsider our approach and our strategy.

[tsmaeder]

With eclipse-che/che-theia#739 being merged, we can map commands, which are global in the devfile (relative to projects) to user-level tasks in Theia.
However, the same is not true for launch configurations (see here: https://code.visualstudio.com/docs/editor/debugging#_launch-configurations) and general preferences.

Also, there is the action type theia-task which I interpret as adding theia tasks not of task type che to the Theia workspace. As long as they are one of the VS Code built-in types (shell/process), I don't expect any problems. But in VS Code, contributed tasks cannot be configured into the user-level tasks.json file, so extensions may make an assumption (the task is configured inside a workspace root), which would not hold if we replicated such tasks to the user-level tasks.json.

[tsmaeder]

In order to proceed with the general goal of enabling multi-root mapping of che workspaces, we need to solve the mapping of che command actions of type "vscode-task" and "vscode-launch".

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.