Che commands should be of type task or launch

[l0rd]

Description

VS Code (and thus Theia) does a clear distinction between a task (linting, building, packaging, testing or deploying) and a launch configuration (run, debug an application).

Currently all Che commands are translated into Theia tasks. As a consequence the UX is bad for run/debug commands. For example, when a user defines a debug command (in a devfile or from the Che dashboard), he won't be able to run it from Theia Debug menu.

This issue is about adding an attribute (or a label or an annotation) to the current Che command model (in a workspace config and in a devfile) so that a user will be able to specify if the command should be translated into a task or a launch config.

N.B. This issue is part of epic #12709 and is not about changing the mechanism that translates Che commands into Theia tasks or launch (there is #12711 for that).

[azatsarynnyy]

I think the goal attribute suits well for that purpose. Now there're Build, Run, Debug values are already used in Che's stacks.json.

[l0rd]

I agree @azatsarynnyy. Now I have 2 questions:

• How can we map that into a devfile?
• Should we restrict the goals to launch/task (or task, run and debug) and provide a error/warning if a user use a goal that we do know how to translate in a theia context?

@slemeur @benoitf what do you think?

[benoitf]

Hello, maybe instead of restricting we can say that there is a default mapping. Only Run and Debug are translated to a launch configuration, the other are considered as tasks.

For devfile

actions:
      - type: start

will be mapped to Run / Launch configuration

and exec type

- name: build
    actions:
      - type: exec
        tool: mvn-stack

to a task ?

[slemeur]

It's a good suggestion to use the goal of the command and depending on that.

If I'm not mistaken, the command's goal now correspond to type in the devfile, correct? Are we handling a defined set of type, if yes, I have not find it in the documentation.

I like the suggestion from @benoitf.

[l0rd]

I think we should allow only a defined set of goals.

If the user misspell a goal we should provide a warning. For example it would be an error if we translate goal: Ran or goal: Runn to a Theia task.

The other things that I find confusing is that goal: Run and goal: Debug has the same exact effect. For example a user will probably want to have in its devfile a command with goal: Run and another command with goal: Debug. But in Theia he will see that both commands can be run in Debug mode. That's weird no?

[gorkem]

vscode has 'group's for tasks. I do not think this is supported on theia but it should be. groups allows vscode to identify a task as build or test. I think we should consider such a classification for commands on devfile as well.

    /**
     * Defines the group to which this task belongs. Also supports to mark
     * a task as the default task in a group.
     */
    group?: "build" | "test" | { kind: "build" | "test"; isDefault: boolean };

[sunix]

what about the goals Task and Launch ? instead of Run/Debug/Build/Test

[l0rd]

@sunix yes that look like the simpler approach, and then we should have groups as @gorkem suggested. @benoitf are you ok with that?

[skabashnyuk]

@l0rd can you provide some examples of how these commands will look like in devfile?

[monaka]

@gorkem I checked it and the current che-theia supports group.

It will improve users' experience by supporting group.

@skabashnyuk IMO, it's enough just adding group object to commands.actions like this.

commands:
  - name: build
    actions:
      - workdir: '${CHE_PROJECTS_ROOT}/mruby'
        type: exec
        command: make
        component: workspace
        group: # Object. optional
          kind: build # String. required
          isDefault: false  # Boolean. optional. default = false

In this way, I suppose this can be added as the minor upgrade (like v1.1.0 ).

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