Run Che command in selected container

[mmorhun]

Signed-off-by: Mykola Morhun mmorhun@redhat.com

What does this PR do?

In some cases it is impossible to figure out container for a command defined in Che workspace devfile. Then such a command is displayed in each container of the workspace in Workspace panel. But when a user clicks on it, Che asks the user to select container in which this command should be run. But in case of clicking on specific node of specific container it is obvious in which container this command should be run this time.
This PR addresses such case and runs the clicked command in the right container.

Example of workspace which has ambiguous commands:

devfile

metadata:
  name: test-tasks
projects:
  - name: NodeJS-Sample-App.git
    source:
      location: 'https://github.com/sleshchenko/NodeJS-Sample-App.git'
      type: git
      branch: master
components:
  - id: eclipse/che-theia/next
    type: cheEditor
    alias: theia-editor
  - referenceContent: |
      ---
      apiVersion: v1
      kind: List
      items:
      -
        apiVersion: apps/v1
        kind: Deployment
        metadata:
          name: mongo
          labels:
            app.kubernetes.io/name: employee-manager
            app.kubernetes.io/component: database
        spec:
          selector:
            matchLabels:
              app.kubernetes.io/name: employee-manager
              app.kubernetes.io/component: database
          template:
            metadata:
              labels:
                app.kubernetes.io/name: employee-manager
                app.kubernetes.io/component: database
              name: mongo
            spec:
              containers:
              - name: mongo
                image: mongo
                ports:
                - name: mongo
                  containerPort: 27017
                volumeMounts:
                    - name: mongo-persistent-storage
                      mountPath: /data/db
              volumes:
                - name: mongo-persistent-storage
                  persistentVolumeClaim:
                    claimName: mongo-persistent-storage
      -
        apiVersion: v1
        kind: Service
        metadata:
          name: mongo
          labels:
            app.kubernetes.io/name: employee-manager
            app.kubernetes.io/component: database
        spec:
          ports:
            - port: 27017
              targetPort: 27017
          selector:
            app.kubernetes.io/name: employee-manager
            app.kubernetes.io/component: database
      -
        apiVersion: v1
        kind: PersistentVolumeClaim
        metadata:
          name: mongo-persistent-storage
          labels:
            app.kubernetes.io/name: employee-manager
            app.kubernetes.io/component: database
        spec:
          accessModes:
          - ReadWriteOnce
          resources:
            requests:
              storage: 1Gi
      -
        apiVersion: apps/v1
        kind: Deployment
        metadata:
          name: nodejs-app
          labels:
            app.kubernetes.io/name: employee-manager
            app.kubernetes.io/component: nodejs-app
        spec:
          selector:
            matchLabels:
              app.kubernetes.io/name: employee-manager
              app.kubernetes.io/component: nodejs-app
          template:
            metadata:
              labels:
                app.kubernetes.io/name: employee-manager
                app.kubernetes.io/component: nodejs-app
              name: nodejs-app
            spec:
              containers:
              - name: web-app
                command: ["tail"]
                args: ["-f", "/dev/null"]
                image: "sleshchenko/nodejs-mongo-sample:latest"
                ports:
                - containerPort: 3000
                  name: http-server
                env:
                  - name: MONGO_HOST
                    value: "mongo"
                  - name: MONGO_PORT
                    value: "27017"
                volumeMounts:
                  - name: projects
                    mountPath: /projects
              volumes:
                - name: projects
                  persistentVolumeClaim:
                    claimName: projects
      -
        apiVersion: v1
        kind: Service
        metadata:
          name: web
          labels:
            app.kubernetes.io/name: employee-manager
            app.kubernetes.io/component: nodejs-app
        spec:
          type: LoadBalancer
          ports:
            - name: web
              port: 80
              targetPort: 3000
              protocol: TCP
          selector:
            app.kubernetes.io/name: employee-manager
            app.kubernetes.io/component: nodejs-app
      -
        apiVersion: extensions/v1beta1
        kind: Ingress
        metadata:
          name: nodejs-ingress
          labels:
            app.kubernetes.io/name: employee-manager
            app.kubernetes.io/component: nodejs-app
          annotations:
            kubernetes.io/ingress.class: "nginx"
        spec:
          rules:
          - host: nodejs.192.168.99.100.nip.io
            http:
              paths:
              - path: /
                backend:
                  serviceName: web
                  servicePort: 80
      -
        apiVersion: v1
        kind: PersistentVolumeClaim
        metadata:
          name: projects
          labels:
            app.kubernetes.io/name: employee-manager
            app.kubernetes.io/component: nodejs-app
        spec:
          accessModes:
          - ReadWriteOnce
          resources:
            requests:
              storage: 1Gi
    type: kubernetes
    alias: employee-manager
    reference: deploy_k8s.yaml
apiVersion: 1.0.0
commands:
  - name: Test ls and echo
    actions:
      - workdir: /home
        type: exec
        command: ls -l && echo "hello world"
        component: employee-manager
  - name: Echo test works
    actions:
      - workdir: /projects
        type: exec
        command: ls -la && echo "hello world"
        component: theia-dev
  - name: Test echo
    actions:
      - type: exec
        command: echo "hello world"
        component: employee-manager
  - name: Test echo
    actions:
      - type: exec
        command: echo "hello world"
        component: employee-manager
  - name: build (test)
    actions:
      - workdir: /projects/theia
        type: exec
        command: yarn
        component: employee-manager

Provides fix for: eclipse-che/che#13764

[che-bot]

E2E Happy path tests of Eclipse Che Single User on K8S (minikube v1.1.1) has failed:

• build details
• "che-theia" docker image: maxura/che-theia:440
• test artifacts
• https://github.com/orgs/eclipse/teams/eclipse-che-qa please check this report.
  Use command "crw-ci-test" to rerun the test.

[benoitf]

Hi, why yarn lock file is totally changed ?

[mmorhun]

@benoitf because I need newer version of some Theia dependencies and I just regenerated yarn.lock file. Anyway we need to update it soon or late. WDYT?

[olexii4]

@mmorhun In the case when we regenerate yarn.lock file just because we need to update it soon or later - add these changes in a separate commit.

[RomanNikitenko]

I tested the changes using commands section of the provided devfile.
It works well for me: the clicked command is run in the right container.

But I noticed that this implementation changes the current behavior.

Before the changes:
The list of problem matchers is displayed before running a task

After the changes:
The list of problem matchers is NOT displayed before running a task

[dmytro-ndp]

crw-ci-test

[che-bot]

E2E Happy path tests of Eclipse Che Single User on K8S (minikube v1.1.1) has been successful:

• build details
• "che-theia" docker image: maxura/che-theia:440

[che-bot]

E2E Happy path tests of Eclipse Che Single User on K8S (minikube v1.1.1) has been successful:

• build details
• "che-theia" docker image: maxura/che-theia:440

[mmorhun]

@RomanNikitenko thanks for your review.
I've investigated the issue which you have and I can say that it doesn't change the current behaviour, just has slightly different one.
Let me explain. I use executeTask API method in my implementation, which consumes task configuration. Under the hood, this method just invokes runTask method of Theia task service, which process given configuration and executes the task. So, if a task has a problem matcher in its configuration - the matcher will be applied. If it doesn't - it doesn't. I retrieve task configuration using fetchTasks API method which returns all available tasks of Che type. Everything what is changed is the target container name, and it is done to avoid select container popup. The only difference between invocations from Workspace panel and Terminal -> Run Task is that if use Task menu and a task doesn't have a problem matcher then a user will be asked to select one. In case of workspace panel user won't be asked to select a problem matcher if task doesn't have one in its configuration.
Now let's look at which commands we have in the Workspace panel. All of them are coming from workspace devfile, so they are designed to be complete and do not bother user with questions about problem matcher or anything else. They have to do their job. And if a task from the Workspace panel should have a problem matcher, I believe, that the right place for defining them is the workspace devfile.

@l0rd @slemeur @benoitf WDYT?

[RomanNikitenko]

@mmorhun
thank you for clarification!

Problem matchers for tasks was added to theia project recently (about 2 weeks) and at the moment user doesn't have ability to define problem matchers for actions with type exec in devfile (but, I guess, user can add it for action with type vscode-task), so list of problem matchers is displayed before running a task first time, then user's choice is saved to configuration and list of problem matchers is not displayed for the task.

So, to be exact - yes, the PR changes the current behavior for first time running task without problem matchers from Workspace panel.

[mmorhun]

@slemeur please take a look

[che-bot]

E2E Happy path tests of Eclipse Che Single User on K8S (minikube v1.1.1) has failed:

• build details
• "che-theia" docker image: maxura/che-theia:440
• test artifacts
• https://github.com/orgs/eclipse/teams/eclipse-che-qa please check this report.
  Use command "crw-ci-test" to rerun the test.

[mmorhun]

crw-ci-test

[che-bot]

E2E Happy path tests of Eclipse Che Single User on K8S (minikube v1.1.1) has been successful:

• build details
• "che-theia" docker image: maxura/che-theia:440