Consolidate Chefile and Factory formats

[slemeur]

Goal

Today we have two recipes that allow to bootstrap a cloud developer workspace and make it portable: Chefile and Factories.

The goal of this epic is to unify the two formats that are used to keep and maintain only a single one. We will keep the Chefile, which is simpler and more readable format (TypeScript). Chefile, with its syntax also allows to write scripts inside of the Chefile, so it's possible to define functions and use conditions for example.

There would be two ways to use a Chefile:

• with a Che running on localhost: by using the CLI
• with a Che running remotely: by using it accross an instance of Che running in the cloud.

Sub-Tasks

Read Chefile in source code repo to create a worksapce
Che must be able to create a workspace from a project's Chefile hosted in the repository. Today this is not possible because it requires to clone the repository to get the Chefile - and the clone of the repository can be handled only in a running workspace.
Che will need the ability to clone the repository (maybe on a temporary container), in order to read the Chefile content and then provide the instructions to create the workspace.

Add CLI command to do a che dir up by passing url of a repository
On the local use case, we require the user to start by doing a local clone of the repository and then use the che dir up command.
We should also add the ability to use the che dir up command and pass the url of a repository as option parameter. In this case, the local clone will not be needed.

Translation engine Chefile -> Factory
Today we use a dedicated Docker container to properly handle the interpretation of Chefiles (and TypeScript syntax).
The idea of this task would be to integrate an engine who is able to interpret a Chefile in order to generate the corresponding factory.json. The factory.json would remain the internal pivot format used server side. (the factory.json will not be exposed anymore to end-users)

Expose only Chefile syntax to the end-user
We would hide the factory.json from the end-user. It would remain accessible from REST API, but we would:

• get ride of the .che.json (currently .codenvy.json) and require only a Chefile
• the user will be able to create a factory by uploading a chefile (dashboard, rest API)
• the user will author factories only using the chefile syntax: we could probably remove all forms from dashboard and just provide an editor with syntax highlighting and autocompletion
• the user will be able to create a Chefile from any existing workspace
• the user will be able to issue a pull request to contribute the Chefile to initial repo

Storage for Chefile
Today, Chefile are hosted on the project's repo.
By consolidating Chefile and Factories, it will mean that we need to store Chefile onto the system.

IDE Post-Loading Actions
With a factory, it is possible to configure post-loading actions to be triggered once the browser IDE is displayed. For example, we can request files to be opened.
Today the Chefile is not able to handle those actions, as we don't have a mechanism to store them with the workspace configuration (and they are interpreted by the client). When executing chedir up locally, it gives the URL to the workspace, but it would be necessary to have a mechanism for post-loading actions so that when the workspace is opened, it knows what have to be executed.

Multi project workspaces support
We will need to add capabilities to the Chefile to handle workspaces with multiple projects in it.

Others Notes

Authentication
Chefile is not handling private repositories or any authentication mecanism. We consider that the user first cloned the repository, and then do achedir up. The authentication is not necessary in this case.
When used remotely, the IDE will handle the authentication scenarios.

Chefile as the only format for workspace configuration
The chefile, should be the only format exposed to the user. The workspace configuration should be exposed (in the dashboard) via only a Chefile

Chefile attributes
There are few options that the Chefile should be able to handle - which would be workspace configuration and settings, such as:

• Activate autosave
• Plugins to be configured and enabled

[slemeur]

Subtask: #7641

[skabashnyuk]

@slemeur should we close this issue because of this #11549?