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?