Changing any of the devfile commands of an existing (and started) workspace from the dashboard is not affecting the workspace (even after restart).
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/
open the workspace and execute the task: it works well

stop the workspace
go to the dashboard and edit the devfile. Change the command to display 'hello che world'

restart the workspace

kubectl version) oc version)minikube version and kubectl version)minishift version and oc version)docker version and kubectl version)devfie, they are copied to a config file when workspace is started. config file and the changes are applied for execution in runtime 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
Most helpful comment
devfie, they are copied to aconfigfile when workspace is started.configfile and the changes are applied for execution in runtimetasks.jsonfile have higher priority than tasks fromdevfile(because user working in the running workspace and if he changes some args for command it's expected to execute this configuration fromtasks.jsonfile, not origin task from devfile)I think the issue can be fixed when we provide synchronization for
configfile anddevfile.At the moment as workaround user can edit label for the task which he customized.