Support Che tasks for multi-root workspaces

[RomanNikitenko]

Is your enhancement related to a problem? Please describe.

At the moment by default user gets /projects as workspace folder.

As you can see there are theia and che-theia projects and all defined in devfile che tasks are stored to /projects/.theia/tasks.json file.

Describe the solution you'd like

We can consider the same example for case when user has multi-root workspace. For this case there are two workspace folders: theia and che-theia.
According to https://code.visualstudio.com/docs/editor/multi-root-workspaces#_tasks each workspace folder can contain tasks.json file with the corresponding configurations.

So user can have a set of task configurations for theia project and a set of task configurations for che-theia project:

• only theia scope configurations are available for running if theia workspace folder is open
• only che-theia scope configurations are available for running if che-theia workspace folder is open
• theia and che-theia scope configurations are available for running in multi-root case

I think we should provide opportunity to define in a devfile source field for a che command to store this one as task in the corresponding tasks.json file.

[sunix]

Should this issue be part of #15529 ?
If i understand we could have a kind of project target.

[tsmaeder]

Generally, is it ok to manipulate "tasks.json" directly? Isn't there API that might take care of multi-root issues?

[RomanNikitenko]

@tsmaeder
I think using API doesn't help us to solve the issue.

I created the issue to provide the mechanism how we can match a task from a devfile to the corresponding workspace folder for multi-root workspace.
So we should have some field like scope or source for che command in a devfile to know which config file should be used to store a task.

[tsmaeder]

VS Code also allows to store tasks globally, into the workspace definition file.

[tsmaeder]

@tsmaeder actually, I don't think it does :-(

[tsmaeder]

Since we're trying to remove obstacles to "multi-root" workspaces, we're taking this on in this sprint.
My approach would be the following:

• Override TaskConfigurationManager to integrate the devfile as a source for global TaskConfigurations.
• Make the tasks in devfile accessible as a resource (tasks.json) that can be opened in the editor. Read-only until we are ready to sync back to the devfile.

Currently, all che tasks are global tasks. If we get support for project-specific tasks in the devfile, we will need to sync to the .theia/tasks.json file.
What worries me a bit is that folks will check that info into their code repo. Should we really replicate checked-in tasks to the devfile? Shouldn't we rather just leave that in the repo? If we check out the source again in another workspace (or the same workspace), the tasks will be there anyway, even if we don't replicate them to the devfile.
@RomanNikitenko what do you think?

[sunix]

To me we should avoid to confuse the user.
Exposing Che commands in tasks.json AND devfile (as workspace config) AND devfile.yaml (in source code in some case) IS CONFUSING FOR THE USER.

So rather than going further in multi-root workspaces support for task ...
... I suggest that we rethink how Che tasks works at the moment and make it easier to edit, view and share through the devfile.

[tsmaeder]

@sunix so what would are you suggesting concretely?

[sunix]

• do not show Che tasks in tasks.json but load it in memory from the devfile (as workspace config)
• from the IDE a way to dynamically edit the devfile (as workspace config) and particular the che tasks
• have a way to synch/push the devfile (as workspace config) into a devfile.yaml of a project

[tsmaeder]

I think the solution I sketched would fulfill point 1 and 2, no?

[sunix]

In your solution you are still using tasks.json, no ?

[tsmaeder]

No, I would just call the Resource tasks.json. It would be backed by the devfile directly, not a disk file.

[davidwindell]

I like the idea of hiding the devfile tasks in the workspace BUT I really think it should at least be possible to extend these tasks via a yml file in the project repo.

[tsmaeder]

@davidwindell would you agree that when you put a tasks file inside a project, it would make no sense to replicate those tasks to the devfile?

[davidwindell]

Yes, I agree as otherwise it would be a maintenance nightmare. The benefit of in-repo tasks is that we don't have to give our developers access to edit the devfile registry (where all of our ~50 projects are) just to add tasks that are re-useable.

[sunix]

In most of the case, Che tasks cannot be decoupled from:

• projects
• components/containers where these are going to be executed

In my opinion, storing just tasks (not devfile) in a project git repo is not a generic maintainable option.

But you can have the devfile registry with a git repo(s) backend where your developers could have write access with moderations (PR) just like a normal git project.

Another option (maybe the best one) could be to add the ability to register projects that have devfile.yaml file in it. edit: created an issue for that: #16377

[tsmaeder]

Once eclipse-theia/theia#7620 is merged, we'll have to update che-theia because the type of TaskConfiguration._scope has changed and is no longer assignement-compatible with the type we're using in the che tasks API transport level. Just making it into string | numbermakes the code compile again.