plugin commands are not in workspace panel

[mingfang]

Commands defined in meta.yaml of plugins, such as https://github.com/eclipse/che-plugin-registry/blob/master/v3/plugins/che-incubator/theia-dev/0.0.1/meta.yaml#L24, are not listed in the workspace panel tree.

The component field is also not filled in task.json

    {
        "type": "che",
        "label": "uname",
        "command": "uname -a",
        "target": {
            "workingDir": "$(project)"
            <missing or empty component field here/>
        }
    }

[tolusha]

/cc @RomanNikitenko

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

[ericwill]

cc @tsmaeder

[tsmaeder]

I'm not sure you can define commands in meta.yml. @skabashnyuk, @amisevsk who is responsible for the defining the meta.yml format?
Also: we get the workspace commands via the Che API (I think workspace.commands), so the Che server would be responsible for including any such commands. Nothing the plugins team can do here @ericwill

[skabashnyuk]

uname command was included in the Workspace API response.

[tsmaeder]

The command in question has the type 'custom'. However, the code in container-service.ts#117 in che-theia filters all commands that are not of type exec.

[tsmaeder]

@skabashnyuk what should we use for determining what is current Che API and how to use it?

[amisevsk]

As far as I know nobody owns the plugin's meta.yaml format -- we've had various additions from various sources. It's still mostly an internal API with an underdefined spec.

The data flow for meta.yamls is

meta.yaml --> plugin broker --> ChePlugin --> Che server

but apart from doing some Theia-specific work (adding the remote runtime, etc.) the broker is basically translating from meta.yaml to ChePlugins.

[skabashnyuk]

@skabashnyuk what should we use for determining what is current Che API and how to use it?

GET /api/workspace/{wsid}
As you can see on the screenshot, commands that come from plugins located in runtime object. These commands combine commands from all plugins + devfile and available only in runtime.

[tsmaeder]

@skabashnyuk I was looking for reference documentation, not examples: you can never be sure whether you have seen all the possible cases with examples.

[skabashnyuk]

https://che.openshift.io/swagger/#!/workspace/getByKey