Add `project` in DevWorkspace CRD spec and deprecate `projects` from the devfile spec

[l0rd]

Is your enhancement related to a problem? Please describe

We are removing projects from the Devfile spec and leave only starterProjects (issue). The reasons:

• when a Devfile lives in a git repo, close to the project source code, projects can (and should) be omitted
• when a Devfile lives outside a git repo, far from the project source code, projects and starterProjects are pretty similar
• when the need is to open multiple projects in the IDE, it’s better to have distinct Devfiles/dw (one per project) rather than one “uber” devfile/dw for all projects

Describe the solution you'd like

Current DW spec

kind: DevWorkspace
apiVersion: workspace.devfile.io/v1alpha2
metadata:
  name: theia-next
spec:
  started: true
  template:
    projects:
      - name: web-nodejs-sample
        git:
          remotes:
            origin: "https://github.com/che-samples/web-nodejs-sample.git"
(...)

Future DW spec

kind: DevWorkspace
apiVersion: workspace.devfile.io/v1alpha2
metadata:
  name: theia-next
spec:
  started: true
  project:
    name: web-nodejs-sample
    git:
      remotes:
        origin: "https://github.com/che-samples/web-nodejs-sample.git"
  template:
    (...)

[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.

[l0rd]

There is an important scenario for which projects is currently the only alternative. That's for unsupported git service provider such as gerrit, gogs, gitea,gitolite, sourcehut etc...) which Che doesn't support properly right now (GitHub, GitLab and Bitbucket are the only services fully supported).

If the repo is public

The devfile is not read at startup because the service cannot figure out its URL. The recommendation in this case is to use the complete raw URL to the devfile in the workspace creation link:

https://<che-host>#<devfile-raw-URL>

but then we need to add the project in the devfile. Or, when it's implemented, use the remote URL parameter described here. So something like:

https://<che-host>#<devfile-raw-URL>?remotes={<git-remote-url>}

If the repo is private

Not only the devfile URL is not known but Che is not able to access that URL because OAuth flow is not supported on services other than GitHub, GitLab or Bitbucket. The recommendation in this case would be to use an "external" devfile (with a project) or again, when it's implemented, use the remote URL parameter described here:

https://<che-host>?remotes={<git-remote-url>}

In this case there are a couple of limitations:

1. the devfile in the git repository won't be used at startup and a default workspace specification will be used instead. Once this is implemented on VS Code, the user should be prompted that a Devfile has been found and if he wants to update the workspace definition.
2. in order to clone the git repository a git credential or SSH key secret should be provisioned in the developer namespace (see documentation here)

[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.