Commands/tasks/launch and workspace configuration synchronization

[l0rd]

Goal

The goal of this epic is to improve the experience related to configuring tasks, commands and launch configs to keep them in sync with the workspace configuration and all the different menus from the IDE.

As a user, I should be able to configure tasks, commands, launch configs and get them kept in sync so that my experience is consistent between the different IDE actions that are available.

Problems

Today, a workspace and its tasks, commands, launch configs, could be configured from different sources, but editing one or the other doesn't keep everything in sync. There are different sources:

• the devfile
• the tasks.json in a .theia folder
• the launch.json in the .theia folder
• the IDE from the different menu options

Those are not yet kept synchronized which cause inconsistency. Examples:

• If a user is adding a task from the IDE, the menu will guide him into adding a task to the tasks.json file, but then the task is not referenced in the devfile.
• Similarly, if the devfile is getting updated, the workspace will need to be restarted to get the changes applied.

Sub-tasks

• Che commands should be of type task or launch Che commands should be of type task or launch #12710

• Dashboard: While editing a devfile of a workspace, user is constantly interrupted by the auto save] Dashboard: While editing a devfile of a workspace, user is constantly interrupted by the auto save #13982

• User defined Che launch commands should be exported in a launch.json file User defined Che launch commands should be exported in a launch.json file #12711

• User defined Che tasks commands should be exported in a tasks.json file User defined Che tasks commands should be exported in a tasks.json file #12712

• Add a Configure Task command in Theia palette

• che task: Cannot run a che command after workspace restart for some containers che task: Cannot run a che command after workspace restart for some containers  #13993

• Implement a che-sync Theia plugin that:

  • sync local launch.json modifications with Che workspace config
  • sync local tasks.json modifications with Che workspace config
  • sync local devfile modifications with Che workspace config

• Implement a devfile-sync Theia plugin that sync Devfile and launch.json/tasks.json modifications

• Workspace panel is not getting update with newly added task Workspace panel is not getting update with newly added task #13666

• When creating new tasks for a project imported in a che workspaces, folder with tasks definition should be named '.che' When creating new tasks for a project imported in a che workspaces, folder with tasks definition should be named '.che' #13391

• Che should auto-detect mvn and npm tasks as VS Code does

• Task: Changing a command in the devfile of an existing workspace is not taken in account Task: Changing a command in the devfile of an existing workspace is not taken in account #13994

[tsmaeder]

This is even more complicated when you think about multiple workspace roots, something we will need in the future.
I don't think syncing is a good approach for two reasons: first, it leads to complicated, error-prone code and second, it does not work well with multi-root workspaces (commands in the devfile are inherently global: which workspace root do you sync them to? What if you remove that project, etc.).
I would advocate for an approach where the devfile is just one more repository for tasks (like tasks.json). The editing experience would be the same as for tasks.json.
In general, I think we need to think about what user-level features we want to enable (that's not clear to me).
Here's a couple of things I think would be useful:

• Do a "configure command" action and have the result live in the devfile
• Edit devfile commands in the IDE as IDE tasks.
• Run devfile commands via the task execution

VS Code currently supports adding tasks and launch configuration sections in in the workspace configuration file. However, the UI is not completely up to handling that: for example, when you do a "configure task" the task configuration always ends up in one of the workspace roots.

One requirement we're seeing is to run tasks contributed by extensions (Quarkus) to different containers. By default, they should probably run in the container where the extension runs that contributed them, but there are cases where that is the wrong one. There should be "run task in container" and "configure container for task" (which would create a configured task in the devfile).

[davidwindell]

It would be ideal if tasks could be defined on a project level and stored in a projects .theia or .vscode folder (tasks.json). As I described above, tasks often change throughout the lifecycle of a project so in a project repo would be the best place for them.

[l0rd]

@tsmaeder you have good points.

I agree that we should avoid synching if possible. One problem we have is that currently the .theia folder doesn't get versioned because it's outside of the project folder (I think that's what @davidwindell is mentioning too). Having a sync mechanism with the devfile (that is versioned) would solve this problem and that's one of the reasons we proposed that. But if .theia could be moved in project folder that may work as well.

[tsmaeder]

It would be ideal if tasks could be defined on a project level and stored in a projects .theia or .vscode folder (tasks.json).

If we move to a setup where we have on workspace root/project, that will be automatically be the case. However, the tasks in the devfile are still global, not specific to a project.

[RomanNikitenko]

We could have some field like scope or source for che command in a devfile to know which workspace folder should be used to store a task: #15540

[davidwindell]

That's a great idea, would have to think about how a sync would work when a project git pull changes the tasks.

[sunix]

100% agree with @tsmaeder

• we should not have any tasks.json any where to store Che commands, It is too confusing for the end users.
• @davidwindell devfile.yaml stored in the project should work. We could have commands (or automated triggers) to synch that with the devfile (workspace config). Another alternative could be to have custom devfile registries that would be built from git. Let me know if this wont work for you. I would be interested to see your usecase.

[sunix]

Conclusion during Che community call discussion:

1. We remove tasks.json from workspace roots. Che commands are to be edited in the devfile (workspace config). We then need to agree what is the best UX to edit the devfile (workspace-config) in che-theia.
2. Project could keep tasks.json file. But that would not be related to Che. Should be a feature in Theia. Che would ask the user in which container to execute it when the task is triggered.

[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.

[tsmaeder]

Unfortunately, we still need to replicate the tasks for now, but this is still kinda bogus

[sunix]

i think the missing pieces "che-sync" shouldn't be done in a Theia plugin but process independent of the editor.
Same for project cloning.

[azatsarynnyy]

Same for project cloning.

fyi: regarding cloning #15973