Improve devfile editing UX

[l0rd]

Is your enhancement related to a problem? Please describe

To simplify the day 1 activities (start a sample workspace, start a workspace from a git repository) we have removed the Devfile editor from the Dashboard as editing a YAML file to create a workspace was a daunting activity for new users.

As a consequence we have sacrificed a day 2 activity, something that more experienced users loved: the devfile editor. From devfile editor in the dashboard allowed to create and edit a devfile (re)start a workspace from it.

Describe the solution you'd like

There will be multiple alternatives:

• Start from no-devfile and progressively build one without editing one line of YAML
• Follow a link to inspect and edit the DevWorkspace object in OpenShift Console
• Advanced Devfile editing experience in VS Code with code completion with the YAML VS Code extension

The progressive editing flow is the following one:

1. start a workspace without Devfile: empty or from a git repository (passed as a URL parameter)
2. in the IDE it will be possible to use a GUI tool to generate or to edit the devfile (no YAML)
3. from the IDE it will be possible to restart a workspace from the created / modified devfile
4. for advanced configuration it will be possible to edit a Devfile YAML with code completion and API documentation in the IDE itself

Subtasks:

• Add an IDE-only workspace sample in the Dashboard getting started (without project) #21554
• Handle gracefully when an invalid devfile is found in a git repository #20738
• When a devfile is not present Che should include a UDI based dev container in the workspace #21340
• Che ignores changes to devfile.yaml and che-editor.yaml after pushing to a git repository (because che-server URLFetcher sometimes caches its results) #21184
• Allowing users to update the workspace if they edit the project devfile in VS Code #18670
• As a User, I want to navigate from DevWorkspace Dashboard view to OpenShift Console DevWorkspace object #22422
• Make "Devfile" on User Dashboard uneditable #22115
• When workspace startup fails, propose to start it in "safe mode" #22228
• Devfile creation walkthroughs #18671
• Rework "Overview" and remove "DevWorkspace" tab from the "Workspace Details" #22612
• Improve options when workspace startup fails #22640

Describe alternatives you've considered

We want to avoid the re-introduction of the user dashboard devfile editor because we want that to happen in the IDE. That's where a developer has the best development experience and that's where they expect to edit their workspace. Having to go back to the dashboard to edit the workspace is awkward. This is a feedback we got recurrently from users.

Additional context

https://issues.redhat.com/browse/CRW-3152

[RickJWagner]

Thank you for considering these important usability issues.
There is a 'catch-22' to consider. If we want to use the IDE to edit the devfile, we need to consider the case of the user that has an invalid devfile (which will prevent starting of the workspace.)

Example: A user wants to develop a new piece of software. They may start with some minimal set of source code, maybe copied from a blog, previous project or generated by something like spring initializer. Any way they do it, they start with some source code, which they probably commit to git.
At this point, we are in the 'problem zone'. The user cannot start a workspace-- they have no devfile. They could take an existing one and add it to the git repo, but the devfile must be perfect (without benefit of some UI to validate it!) or the dev workspace will not start. The cycle to resolve the issue is:

1. Edit the devfile (without a validating IDE)
2. Commit the change
3. Try again to start the dev space, hoping this time it will succeed and provide the IDE that will allow editing the devfile. (Repeat as needed).

One possibility: Provide a known minimal devfile that is very robust and should almost always be able to start a dev space. In the above scenario, the user would add this 'bulletproof devfile' to the project along with the initial source. The user could then start the dev space and use the available IDE to edit the 'bulletproof' devfile, transforming it into whatever is needed.

There are probably other good paths forward also. Just please keep in mind that we cannot use the IDE to validate/edit the devfile if the workspace cannot start because of an invalid devfile.

[l0rd]

@RickJWagner do you think that #20738 and the following warning message would help?

[RickJWagner]

Yes, thanks for that @l0rd . I hadn't seen #20738, that will help nicely.

[nickboldt]

any further progress on this? we were at 5 of 7 tasks complete in December... should the other two be raised as priority for the next sprint?

[l0rd]

Both remaining issues are in Team B sprint backlog

[ibuziuk]

Exluding JetBrains from the epic - #22487 and adding to https://issues.redhat.com/browse/CRW-3398
We can resolve the issue once we publish the walkthrough extension and add it by default to Dev Spaces

[ibuziuk]

@vitaliy-guliy I believe we can close the epic once vscode walkthrough extension is added by default to che-code

[vitaliy-guliy]

A pull request that includes the extension into built-ins che-incubator/che-code#326
I would like to have the latest tag for the extension at open-vsix. It will allow us to update and publish a new version of the extension without updating the reference in che-code.

[l0rd]

latest should work. Does it fail for you?

Anyway @vitaliy-guliy if you have an open-vsx.org user I would like to add you as a member of the Devfile namespace. @ibuziuk that's for you as well.

[vitaliy-guliy]

latest should work. Does it fail for you?

It's strange I missed it.

But it seems vs code builder wants to have a precise version

2283.6 [14:14:39] Error: Request https://open-vsx.org/vscode/gallery/publishers/devfile/vsextensions/vscode-devfile/latest/vspackage failed with status code: 404

With 0.0.2 the following request is succeeded

https://open-vsx.org/vscode/gallery/publishers/devfile/vsextensions/vscode-devfile/0.0.2/vspackage

[vitaliy-guliy]

There is a regression in VS Code that made not possible to add a container endpoint, environment variable and a command
microsoft/vscode#204522

From the good news, the issue was added to February milestone and should be fixed soon.

[ibuziuk]

@vitaliy-guliy I believe we can close the epic once the regression is fixed on VS Code end

[ibuziuk]

@vitaliy-guliy the issue you opened has been autoclosed. is it fixed now in 7.82.0 - microsoft/vscode#204522

[vitaliy-guliy]

@vitaliy-guliy the issue you opened has been autoclosed. is it fixed now in 7.82.0 - microsoft/vscode#204522

Have just checked it on Dev Spaces 3.12 with Che Code 7.82.1 (VS Code 1.87.0) and can confirm the bug is still there.

[vitaliy-guliy]

The extension is working fine in che-code 7.84.0, bug with popups was fixed in the upstream.