Ensure devfiles available on the registry are compatible with devworkspace

[slemeur]

The goal of this issue is to make sure that all the devfile that are provided in the registry are tested and made compatible with devworkspace and in line with #679

Which area/kind this issue is related to?
/area registry
/area devworkspace

Stacks fixes:

• Use NON-terminating container components (PR)
• Replace ${PROJECTS_ROOT} with ${PROJECT_SOURCE} in commands workingDir
• Replace hardcoded /project(s) with ${PROJECT_SOURCE} in commands workingDir (PR)
• Add various mechanisms for preventing Eclipse Che breakages after updates in devfile GitHub org eclipse-che/che#21389

Samples fixes:

• Remove invalid buildguidance components
• Some container components use a non existing image (e.g. quay.io/eclipse/che-java11-maven:nightly).
• Use schemaVersion >= 2.1.0
• Remove projectStarter and project from the Devfiles in a git repository
• Sync devfile.yaml published at registry.devfile.io and the ones in the git repositories
• Sync latest stacks and samples devfiles

[l0rd]

Che currently shows on its landing page a list of "Getting Started" projects. That's a list of GitHub repos or zip files that have a devfile at their root. It's important that Getting Started have a devfile at their root if we want to drive Devfile adoption. And Che is migrating all "Getting Started" to zip files instead of GitHub repos because that provides better performances and support air-gap environment by default.

To use the Devfile Registry as the source for Che "Getting Started" we could use the Devfile Registry samples. That was the original idea. But that may not be the best option (see below the problems for samples). The alternative is to use the Devfile Registry stacks. That means that, at Che build time, the Devfile Registry stacks are fetched and projects zip files are created. The zip files should include the stack Devfile without the "projects" or "projectStarter" section.

Anyway this is a list of problems that need to be addressed to adopt the Devfile Registry in Che:

General devfiles problems:

• Some container components use a terminating image (e.g. registry.access.redhat.com/ubi8/nodejs-14:latest), without specifying a non terminating command / args.
• Some commands.exec.commandlLine have the path harcoded to /project. Special variables $PROJECTS_ROOT $PROJECT_SOURCE should be used instead.
• Some commands.exec.commandlLine use$PROJECTS_ROOT but $PROJECTS_ROOT/<project-name> $PROJECT_SOURCE should be used instead.
• Che getting started are currently using the Universal Developer Image
• We should contribute the Che "Getting Started" that are missing among the Devfile Registry stacks
• We should contribute a Che / DevWorkspace test for PR check and CI
• The projectStarters should contain a .vsode/extensions.json and .vscode/launch.json
• $DEBUG_PORT should be defined
• The debug endpoint should be specified with exposure: none

Specific samples problems:

• There are just 4 samples vs 30 in CRW/Che today.
• Devfiles include a buildguidance component that is invalid
• Some container components use a non existing image (e.g. quay.io/eclipse/che-java11-maven:nightly).
• Devfiles use spec 2.0.0 but Che requires >= 2.1.0
• Some devfiles have a projectStarter or project (but are already included in a project).
• devfile.yaml published at registry.devfile.io and the ones in the git repository are out of sync (maybe a change in the git repo happened after the build of the registry?).
• stacks and samples are out of sync

[kadel]

• Some commands.exec.commandlLine use$PROJECTS_ROOT but $PROJECTS_ROOT/<project-name> should used instead.

This item can be problematic. Where would the project-name come from if there is no project section in devfile?

[l0rd]

That’s a good point @kadel. After some thoughts this morning I concluded that we should use `$PROJECT_SOURCE` in all single-project devfiles (all devfiles in the registry).

[l0rd]

I have updated my comment suggesting to use $PROJECT_SOURCE