Setup Devfile implementation plan fro Phase 1

[skabashnyuk]

Description

The goal of this task is to dive into the task #11549 and provide some implementation plan for the first iteration.

[skabashnyuk]

Plan to have three REST Methods at

Path("devfile")
public class DefFileService extends Service  {

//Create a workspace by providing the url to the repository
@POST
@Produces(APPLICATION_JSON)
public Response create(@QueryParam("repo_url") String repo_url){
...
}


// generate a workspace by sending a devfile to a rest API
// Initially this method will return empty workspace configuration.
// And will start che-devfile-broker on a background to clone sources and get devfile.
@POST
@Consumes("text/yml")
@Produces(APPLICATION_JSON)
public Response createFromYaml(DevFile defFile){
...
}



// generate the devfile based on an existing workspace
// key = workspace12345678
// key = namespace/workspace_name
// key = namespace_part_1/namespace_part_2/workspace_name
//  See get workspace by id aka key.
@GET
@Path("/{key:.*}")
@Produces("text/yml")
public Response createFromYaml(@PathParam("key") String key){
...
}

}

Example of yaml functionality for Phase 1

---
specVersion: 0.0.1
name: petclinic-dev-environment
projects:
  - name: petclinic
    source:
      type: git
      location: 'git@github.com:spring-projects/spring-petclinic.git'
tools:
  - name: theia-ide
    definition:
      chePlugin:
        name: theia:0.0.3
  - name: jdt.ls
    definition:
      chePlugin:
        name: theia-jdtls:0.0.3
commands:
  - name: build
    toolsCommands:
      - tool: mvn-stack
        action:
          exec:
            command: mvn package
            workdir: /projects/spring-petclinic 
  - name: run
    toolsCommands:
      - tool: mysql
        action: start
      - tool: mvn-stack
        action:
          exec:
            command: mvn spring-boot:run
            workdir: /projects/spring-petclinic 

[mshaposhnik]

Implementation plan :

• local part of devfile feature Implementation of local part of devfile feature #11832
• remote part of devfile feature Plan and POC implementation of remote part of devfile feature #11833

[garagatyi]

@skabashnyuk I have some question. Would you be willing to elaborate?

• some REST methods produce JSON and some YAML. Is it a typo or design?
• theia-ide is editor, not plugin. Are you suppose that we won't differentiate them in the dev file model?
• in the tool object, there is a definition field that encapsulates che plugin. Are there any other fields or this is some wrapper needed for some particular reason?
• command matches against a tool, but the tool can have multiple containers. How devfile would correlate them?
• can toolsCommands field be simplified? It seems a bit too complex and it would be cool to have devfile clear for the better UX

[mshaposhnik]

I expect tools to be be like:

tools:
- name: "editor"
  definition:
    chePlugin:
      name: "org.eclipse.che.editor.theia:1.0.0"
- name: "che-machine-exec-plugin"
  definition:
    chePlugin:
      name: "che-machine-exec-plugin:0.0.1"
- name: "che-jdtls-plugin"
  definition:
    chePlugin:
      name: "che-jdtls-plugin:0.0.1"

[skabashnyuk]

some REST methods produce JSON and some YAML. Is it a typo or design?

By design.
DevFile->Workspace produces json
Workspace -> Devfile produces yaml

theia-ide is editor, not plugin. Are you suppose that we won't differentiate them in the dev file model?

I guesses you right. Copy/past from. https://github.com/l0rd/devfile/blob/master/petclinic.yaml @l0rd can you confirm?

command matches against a tool, but the tool can have multiple containers. How devfile would correlate them?

This use case postponed to next iteration for simplification. Now we considering that tool = 1 container.

can toolsCommands field be simplified? It seems a bit too complex and it would be cool to have devfile clear for the better UX

Proposals?

[garagatyi]

can toolsCommands field be simplified? It seems a bit too complex and it would be cool to have devfile clear for the better UX

Proposals?

just commands

[garagatyi]

@skabashnyuk tnx for the explanation

[skabashnyuk]

Initial plan added to the upstream epic header #11549

[l0rd]

Answering @garagatyi comments

theia-ide is editor, not plugin. Are you suppose that we won't differentiate them in the dev file model?

I think that at the time of the devfile definition we had not made a distinction between plugins and editors or that the distinction was blurry. I am ok to have:

- name: "editor"
  definition:
    cheEditor:
      name: "org.eclipse.che.editor.theia:1.0.0"

Anyway devfile wasn't designed to describe a Che workspaces but to define a development environment that could be used by any dev tool (not only graphical IDE). That's why it's all about generic tools.

in the tool object, there is a definition field that encapsulates che plugin. Are there any other fields or this is some wrapper needed for some particular reason?

The full model is https://github.com/l0rd/devfile#third-generation-devfile. And this is just a draft so any idea for improvement is very welcome.

can toolsCommands field be simplified? It seems a bit too complex and it would be cool to have devfile clear for the better UX

Yes the simpler the better but renaming commands.toolsCommands with commands.commands doesn't look like an option. Maybe commands.tools:

commands:
  - name: build
    tools:
      - name: mvn-stack
       (...)

[garagatyi]

Yes the simpler the better but renaming commands.toolsCommands with commands.commands doesn't look like an option.

Sergii and I were suggesting actions.items:

actions:
  - name: re-run
    items:
      - tool: maven-sidecar
        action:
          type: exec
          command: mvn spring-boot:run
          workdir: /projects/spring-petclinic