Propose to users to udpate the workspace if they edit the proejct devfile from VS Code

[l0rd]

Is your enhancement related to a problem? Please describe.

When editing a project devfile in VS Code, the workspace doesn’t get updated automatically.

Describe the solution you'd like

VS Code should watch for changes (including creation or deletion) of devfile.yaml and .devfile.yaml and when it happens propose to the user:

You have made some changes to this repository's devfile.
Do you want to apply them and restart your development environment?

                      || Restart || Continue Editing || Don't Ask again ||

[sleshchenko]

I think SIDECAR_POLICY: dev-container makes flow more complex and tricker for syncing changes back to file system. Maybe we can keep sidecars model for Che Theia (plugins will live in separate DevWorkspaceTemplates) and using dev container will be used after we switched VSCode to that.

[azatsarynnyy]

We've discussed this epic internally, during several calls - it was decided to postpone the work. Currently, there's no way to update a DevWorkspace with the user's Devfile. If I understand correctly, there're some steps are required from DWO side. Also, we've talked with Florent - he can help us with an intermediate library for Devfile->DevWorkspace synchronization. On Che-Theia side, we've prepared a functionality for tracking the file changes and proposing the user a corresponding action - https://github.com/eclipse-che/che-theia/pull/1095.

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

[azatsarynnyy]

/remove-lifecycle stale

[azatsarynnyy]

It doesn't look like an epic, so I've updated the labels.

[vitaliy-guliy]

I'm thinking about having some kind of rollback in case the user mistype something. Being able to edit the devfile via dashboard is good option, but what would be much better - is to store current DevWorkspace object somewhere before applying changes.

[RomanNikitenko]

I'm thinking about having some kind of rollback in case the user mistype something. Being able to edit the devfile via dashboard is good option, but what would be much better - is to store current DevWorkspace object somewhere before applying changes.

I think we should implement it as simple as possible first, then we can improve the behaviour step by step.

[azatsarynnyy]

As we now have the VS Code command for restarting a DevWorkspace, the next step we can add to this UX is checking if the user's Devfile was modified.

If it was, the user could be prompted to restart the DevWorkspce in one of the two modes:

• regular restart (ignoring the Devfile changes)
• restart with applying the Devfile changes (replacing the DevWorkspace template)

WDYT?

[l0rd]

@azatsarynnyy 👍

For confirmation: this is not about adding a file watcher mechanism and it's not about prompting the user when he edits the file right?

And maybe, to avoid making "restart" too smart, we could initially add a separate "restart from local devfile" action.

[azatsarynnyy]

For confirmation: this is not about adding a file watcher mechanism and it's not about prompting the user when he edits the file right?

That's correct.

And maybe, to avoid making "restart" too smart, we could initially add a separate "restart from local devfile" action.

+1

[RomanNikitenko]

I use DevWorkspace Generator library to generate new content based on the devfile changes. At the moment it's possible to pass editor description as a content or as a path on file system to generate DevfileContext. I created a PR to add an ability to pass a URL of yaml file as editor description (see here).

It helps to generate a new DevfileContext when contributions has uri field with the reference to editor description:

But it's still unclear for me how to get editor description on a VS Code extension side when contributions comes without uri:

[RomanNikitenko]

I've added an ability to apply devfile changes and restart a workspace by using Restart Wrokspace From Local Devfile action. The corresponding PR was merged today.

@l0rd @azatsarynnyy Do we still consider to add a file watcher, track devfile and display the notification as it's described in the issue? I don't mind - just to confirm it.

I'm concerned a little how to avoid annoying behaviour. Let's consider as an example:

• user is editing a devfile
• user stopped to edit for 2 seconds(actually - what time we should use here?), but he/she is going to continue edit it
• the notification is displayed
• user select Continue editing and starts to edit again
• the pause for few seconds leads to displaying the notification again

Yes, I know that there is Don't Ask Again option, but then maybe it makes sense to display another notification, like It's possible to apply your changes using Restart Workspace From Local Devfile action from command palette. Maybe user selects Continue editing because he/she doesn't know another way to restart a workspace except click on the Restart option on the notification directly...

[azatsarynnyy]

@RomanNikitenko see the comment above: https://github.com/eclipse/che/issues/18670#issuecomment-1425726703

I believe the work is done and we can close this issue.

[devstudio-release]

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

• https://github.com/eclipse-che/che-theia/pull/1095