Che: Task: Changing a command in the devfile of an existing workspace is not taken in account

Created on 24 Jul 2019  Â·  10Comments  Â·  Source: eclipse/che

Describe the bug

Changing any of the devfile commands of an existing (and started) workspace from the dashboard is not affecting the workspace (even after restart).

Che version

  • [ ] latest
  • [x] nightly
  • [ ] other: please specify

Steps to reproduce

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

    $ chectl workspace:start -f <(chectl devfile:generate --name=test-task-change-devfile --dockerimage=sunix/git-devtools --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-change-devfile
    
    apiVersion: 1.0.0
    metadata:
      name: test-task-change-devfile
    components:
      - alias: sunix-git-devtools
        type: dockerimage
        image: sunix/git-devtools
        memoryLimit: 512M
        mountSources: true
        command:
          - tail
        args:
          - '-f'
          - /dev/null
    commands:
      - name: echo hello world
        actions:
          - type: exec
            command: echo hello world
            component: sunix-git-devtools
            workdir: /projects/
    
  2. open the workspace and execute the task: it works well
    Eclipse Che | test-task-change-devfile - Google Chrome_361

  3. stop the workspace

  4. go to the dashboard and edit the devfile. Change the command to display 'hello che world'
    Selection_362

  5. restart the workspace

  6. rerun the task. It is displaying 'hello world' and not 'hello che world'
    Eclipse Che | test-task-change-devfile - Google Chrome_363

Runtime

  • [ ] kubernetes (include output of kubectl version)
  • [ ] Openshift (include output of oc version)
  • [x] minikube (include output of minikube version and kubectl version)
  • [ ] minishift (include output of minishift version and oc version)
  • [ ] docker-desktop + K8S (include output of docker version and kubectl version)
  • [ ] other: (please specify)

Screenshots

Installation method

  • [x] chectl
  • [ ] che-operator
  • [ ] minishift-addon
  • [ ] I don't know

Environment

  • [x] my computer

    • [ ] Windows

    • [x] Linux

    • [ ] macOS

  • [ ] Cloud

    • [ ] Amazon

    • [ ] Azure

    • [ ] GCE

    • [ ] other (please specify)

  • [ ] other: please specify

Additional context

areplugins kinbug

Most helpful comment

  • We have tasks in a devfie, they are copied to a config file when workspace is started.
  • User can edit the tasks in a config file and the changes are applied for execution in runtime
  • We have conflict if user doesn't change the label for the task - we have one task from devfile and one from config file with the same label.
  • I proposed to add some prefix if we have conflict, and it was another opinion to avoid prefixing
  • At the moment the tasks from tasks.json file have higher priority than tasks from devfile (because user working in the running workspace and if he changes some args for command it's expected to execute this configuration from tasks.json file, not origin task from devfile)

I think the issue can be fixed when we provide synchronization for config file and devfile.
At the moment as workaround user can edit label for the task which he customized.

All 10 comments

  • We have tasks in a devfie, they are copied to a config file when workspace is started.
  • User can edit the tasks in a config file and the changes are applied for execution in runtime
  • We have conflict if user doesn't change the label for the task - we have one task from devfile and one from config file with the same label.
  • I proposed to add some prefix if we have conflict, and it was another opinion to avoid prefixing
  • At the moment the tasks from tasks.json file have higher priority than tasks from devfile (because user working in the running workspace and if he changes some args for command it's expected to execute this configuration from tasks.json file, not origin task from devfile)

I think the issue can be fixed when we provide synchronization for config file and devfile.
At the moment as workaround user can edit label for the task which he customized.

There is no conflict, changes on tasks.json should be applied to the devfile (synch). Don't spend time to resolve the conflicts.
For the moment we expect that devfile changes override tasks.json at every start. I would say that as long as we don't have the synch back, devfile should win over the tasks.json.

Do we have ability to recognize on plugin side - is it workspace start/restart or user is refreshing a page?

https://github.com/eclipse/che-theia/blob/master/plugins/factory-plugin/src/factory-plugin.ts#L17

export async function start(context: theia.PluginContext) {

is invoked at every browser refresh.

https://github.com/eclipse/che-theia/blob/master/plugins/factory-plugin/src/factory-plugin.ts#L17

export async function start(context: theia.PluginContext) {

is invoked at every browser refresh.

Yes, and the same is invoked when workspace has started.
Correct?

So do you mean that devfile changes override tasks.json at every browser refresh?
Or we have ability to recognize on plugin side the difference between browser refresh and start/restart of a workspace

I would behave like if synchronisation were implemented.

changes on tasks.json should be applied to the devfile

Even if user adds own custom task? Should it be reflected in devfile?

changes on tasks.json should be applied to the devfile

Even if user adds own custom task? Should it be reflected in devfile?

I would say yes if synchronisation is implemented

setting area/plugins as it looks like related to https://github.com/eclipse/che-theia/tree/master/plugins/task-plugin

This should be addressed by my work on https://github.com/eclipse/che/issues/15540

Was this page helpful?
0 / 5 - 0 ratings