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

Describe the bug

Cannot rerun commands that are targeting a plugin container after restart of a workspace.

Che version

nightly

Steps to reproduce

start a workspace with this devfile containing a command that would run on a plugin sidecar container. For instance:

 $ chectl workspace:start -f <(chectl devfile:generate --name=test-task-bug-restart --language=java --command="echo hello world")
   ✔ Retrieving Che Server URL...http://che-che.192.168.39.13.nip.io
   ✔ Verify if Che server is running...RUNNING (auth disabled)
   ✔ Create workspace from Devfile /dev/fd/63
 
 Workspace IDE URL:
 http://che-che.192.168.39.13.nip.io/dashboard/#/ide/che/test-task-bug-restart

apiVersion: 1.0.0
metadata:
  name: test-task-bug-restart
components:
  - type: chePlugin
    alias: java-ls
    id: redhat/java/latest
commands:
  - name: echo hello world
    actions:
      - type: exec
        command: echo hello world
        component: java-ls
        workdir: /projects/

open the workspace and execute the task: it works well
stop the workspace
restart it and reopen it
Try to run the task again, it doesn’t work anymore. The terminal is appearing but nothing is executed.

The error Uncaught (in promise) Error: container with name vscode-javaebs was not found. For workspace: workspaceeau9fy5dqm79n36l. But the vscode-javaebs was the container name when it started the first time. Fixing the /projects/.theia/tasks.json with the right machineName works.

Expected behavior

The task is supposed to be running after restart and display “hello world” (for the previous example)

Runtime

minikube (include output of minikube version and kubectl version)

Installation method

chectl

Environment

my computer
- Linux

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 25 (25 by maintainers)

Most upvoted comments

Isn’t the solution as simple as supporting component on target fields for task.json?

This is what I get when I to a Configure Task

 {
            "type": "che",
            "label": "echo",
            "command": "echo me",
            "target": {
                "workingDir": "/projects/theia",
                "containerName": "che-dev"
            }
        }

If we support component as a target such as below, we would no longer have tasks that goes stale.

{
            "type": "che",
            "label": "echo",
            "command": "echo me",
            "target": {
                "workingDir": "/projects/theia",
                "component": "theia-editor"
            }
 }

In short, implement mapping component to a container on the task plugin and modify Configure command to preserve component name as part of the target.

gorkem on Aug 15, 2019

We should have the devfile overrides tasks.json at workspace restart.

Editing tasks.json and having those changes persisted is much more valuable to me than having changes to the devfile override tasks.json.

Editing devfiles is an enormous pain (see https://github.com/eclipse/che/issues/13982) and not easily accessible. OTOH, I’ve frequently modified tasks.json to update or change commands, even just to test devfile improvements. If the server is to overwrite my tasks.json with what’s in the devfile, that would be bad UX.

In an even more involved use-case, having the devfile overwrite tasks.json would make working in a Che workspace for longer than “trying it out” very painful, since every task change would require

Copy devfile config to external editor (and understand its structure)
Modify commands fields (knowing that they will override tasks.json
Restart workspace

In environments where your workspace is stopped after 30 minutes of idling, this completely ends usability.

amisevsk on Aug 1, 2019