che icon indicating copy to clipboard operation
che copied to clipboard

It's not possible to run a Task in Che-Code if it's not `che` type

Open azatsarynnyy opened this issue 3 years ago • 6 comments

Describe the bug

If tasks.json file contains a task of non-che type (e.g. shell), it can't be launched.

Che version

next (development version)

Steps to reproduce

  1. Start a workspace with the Che-Code editor.
  2. Run any non-che task defined in the tasks.json file.

Test tasks.json can be created with Terminal > Configure Tasks... > Create tasks.json file from template > maven.

Terminal panel is open, but the task is not run.

Expected behavior

A task should be run in a default (usually tools) container.

Runtime

OpenShift

Screenshots

image

Installation method

chectl/next

Environment

Linux

Eclipse Che Logs

No response

Additional context

No response

azatsarynnyy avatar Jun 14 '22 16:06 azatsarynnyy

It seems I have the same issue with / Eclipse Che VS Code Version: 1.68.0 / IDE: che-incubator/che-code/insiders / Chrome 102.0.5005.115 / Windows 10 I could not run shell tasks from tasks.json (looks like a terminal process hangs without start executing, showing only the first message "> Executing task ... <") The same shell commands from embedded IDE terminal works ok. The default shell task example created from drop-down menus (with echo) also doesn't work.

Ratgor avatar Jun 30 '22 09:06 Ratgor

It's because the task is sent to machine-exec component for execution in a target container. In the case of non-Che tasks (shell, etc.) the target container can't be specified, so machine-exec doesn't know where to execute it. We need to rework it to execute any non-Che task in a single container or probably ask the user interactively to specify the target container.

azatsarynnyy avatar Jun 30 '22 16:06 azatsarynnyy

in my case, i would expect to be executed int he same container than the VS Code extension. (I do not know if it would be a common default expectation but as it is the SV Code extension which is executing the task, it seems quite natural)

apupier avatar Jun 30 '22 18:06 apupier

@azatsarynnyy it looks like there is workaround: the task label should match the container name.

l0rd avatar Aug 17 '22 16:08 l0rd

in my case, i would expect to be executed int he same container than the VS Code extension. (I do not know if it would be a common default expectation but as it is the SV Code extension which is executing the task, it seems quite natural)

@apupier when using a VS Code based workspace the extensions (and VS Code itself) run in the Devfile first container. Running the extensions in sidecar containers (aka running extensions remotely) is not supported with VS Code.

l0rd avatar Aug 17 '22 16:08 l0rd

Downstream issue

l0rd avatar Sep 20 '22 12:09 l0rd

@azatsarynnyy can we close this? Asking to decide if we can include it in the 7.55 release notes

l0rd avatar Oct 06 '22 12:10 l0rd

@l0rd yes, it's done and we can close it. We restored the VS Code native terminal in Che-Code (https://github.com/che-incubator/che-code/pull/124). So, all task types supported by vanilla VS Code can now be run in Che-Code.

azatsarynnyy avatar Oct 06 '22 13:10 azatsarynnyy

sync'd to Red Hat JIRA https://issues.redhat.com/browse/CRW-3855

devstudio-release avatar Jan 14 '23 03:01 devstudio-release