Support the Devfile Composite Commands in VS Code

[azatsarynnyy]

Is your enhancement related to a problem? Please describe

Devfile has a notion of Composite Commands. It allows connecting multiple Commands together by defining a single Composite Command. E.g.:

commands:
  - id: package
    exec:
      component: tools
      commandLine: 'mvn package'
      group:
        kind: build
  - id: install
    exec:
      component: tools
      commandLine: 'mvn install'
      group:
        kind: build
        isDefault: true
  - id: installAndPackage
    composite:
      commands:
        - install
        - package
      parallel: false

Currently, VS Code editor in Che doesn't support the Devfile Composite Commands. So, the user isn't able to use them in any way.

Describe the solution you'd like

VS Code has a notion of the Compound Tasks which we can rely on when translating the Devfile's Composite Commands.
The example above can be translated to something like:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "package",
      "command": "mvn",
      "args": ["package"]
    },
    {
      "label": "Install",
      "command": "mvn",
      "args": ["install"]
    },
    {
      "label": "installAndPackage",
      "dependsOn": ["package", "Install"]
    }
  ]
}

Describe alternatives you've considered

No response

Additional context

No response

[azatsarynnyy]

The main challenge here is that the VS Code Extension Task API doesn't allow the extensions to provide the Compound Tasks. We need to find a different way how we can provide the Compound Tasks to VS Code.

One of the options is creating the tasks.json directly from our extension. A big drawback of such an approach is that it requires additional functionality to keep both definitions in sync: Devfile Composite Command and VS Code Compound Task. That would add much more complexity to the system which is undesirable, of course.

[RomanNikitenko]

I investigated a little the problem:

• we provide devfile commands as VS Code tasks using TaskProvider entity
• I debugged source code and found that dependsOn property is ignored on the VS Code side for tasks which come from TaskProvider - so Artem is right that VS Code Task API doesn't support compound tasks
• as a solution - we could provide devfile commands as User level VS Code tasks
• moving devfile tasks on the User level could bring not only support of compound devfile tasks, but also an ability to edit them directly from IDE
• the problem is: only shell and process VS Code tasks are supported on the User level. At the same time we use CustomExecution (to use machine-exec).
• anyway it would be nice to have an ability to edit devfile tasks directly from IDE. At the moment Che-Code allows to apply configure action for the devfile tasks, so it's possible to edit a task (by editing tasks.json file), but the task fails when user runs it:

edit_devfile_task.mp4

I guess that we don't consider providing devfile commands as configured VS Code tasks (tasks.json usage), so at the moment I don't see a good way to support compound devfile commands.
About an ability to edit devifle commands directly from IDE - we could consider editing them directly in the devfile and watching changes to apply them.

[RomanNikitenko]

We discussed this problem within our meeting today and @l0rd suggested the following idea:

• there is converting devfile commands to VS Code tasks step
• we could filter devfile composite commands at that ^^ step and form a command field for the corresponding VS Code task.

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

[ahussey-redhat]

/remove-lifecycle stale

[ahussey-redhat]

Is there anything you need from me?

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

[ahussey-redhat]

/remove-lifecycle stale