When a devfile is not present Che should include a UDI based dev container in the workspace

[nickboldt]

Is your enhancement related to a problem? Please describe

Today in #20705 we have the ability to autoload a default v2 devfile when none is present in the git project's repo. Cool beans.

However, if the project needs build tools, like the ones provided by the UDI sidecar, none will be present until the user customize the workspace components.

So... while it's great we can load a project for any git repo, it's of limited usefulness if we can't then compile/run/test/debug the code.

Describe the solution you'd like

OOTB when no devfile is present, the default devfile should include the Che or Dev Spaces UDI image as an available sidecar, so users can open a terminal in that container and at least run build commands (java, javac, mvn, gradle, python, etc.)

As in all things Che, this functionality needs to be whitelabel'd/skinnable/extensible so it can easily be configured to load a DIFFERENT default UDI image.

Describe alternatives you've considered

Document how to write your own devfiles and while generating a default devfile with no build environment, open a README in the workspace saying "so we opened your project, but since you don't define a devfile, we can't know what compilation environments you might want. Here's the boilerplate code to add the UDI sidecar to your generated devfile. Once updated, please save your changes, close the workspace, and reload it from the updated project w/ the devfile in it."

It puts the effort onto the user so the OOTB experience is more manual work, but it saves the effort for the dev team to include the UDI image in the default devfile.

Additional context

Subtasks:

• Extend the DevWorkspaceTemplate spec with containers contributions devfile/devworkspace-operator#656
• Copy and start editors in one of the Devfile containers #21354
• Allow an admin to specify Che default editor and containers #21353

[l0rd]

Rather than leverage cheFlavor we should introduce a workspaces.defaultComponent property in CheCluster CRD. Che default value should be a component of type container using quay.io/devfile/universal-developer-image as image:

(...)
workspaces:
  (...)
  defaultComponent: |
    name: universal-developer-image
    container:
        image: quay.io/devfile/universal-developer-image:ubi8-latest
        memoryRequest: 256M
        memoryLimit: 1536M
        cpuRequest: 0.1
        cpuLimit: 0.5
(...)

[l0rd]

Also note that to introduce a defaultComponent there are a couple of preliminary issues to address:

We should support only one way to inject an editor

Currently Theia runs in its own sidecar whereas VS Code is injected in the dev component. The consequence is that in a no-devfile scenario the behavior is different based on the editor:

• if the editor is Theia: the workspace is started and the dev container is Theia container
• if the editor is VS Code: the workspace fails to start because no dev container has been specified

Rather than supporting both scenarios we should:

• Copy and start editors in one of the Devfile containers #21354

Editors spec should allow to override some hosting container properties

Theia has some pre-requisites (env variables, endpoints, memory, cpu etc...) and VS Code has it's own. We want to let developers to choose their editor but we want to have one unique defaultComponent:

• Extend the DevWorkspaceTemplate spec with containers contributions devfile/devworkspace-operator#656

[benoitf]

Note that the default component if missing is defined for Che Code editor there: https://github.com/eclipse-che/che-plugin-registry/blob/main/che-editors.yaml#L502-L551

It should be handled by devfile/devworkspace-operator#656

[nickboldt]

Closing as this works downstream in 3.3 based on Mario's tests.