Import code flow: Start workspace from Che devfile

[sbose78]

If the repo has a Che devfile, the imported repo should use the devfile to start a workspace.
See eclipse-che/che#11549

[ibuziuk]

We had a call where @skabashnyuk and @mshaposhnik presented early version of devfile. Basically, from implementation perspective support of devfile in osio flow should be pretty easy to implement. che-starter could detect devfile in the repository and send POST /api/devfile request to Che server with devfile definition in the body e.g.:

---
version: 0.0.1
name: petclinic-dev-environment
projects:
  - name: petclinic
    source:
      type: git
      location: 'https://github.com/spring-projects/spring-petclinic.git'
tools:
  - name: theia-ide
    type: cheEditor
    id: org.eclipse.che.editor.theia:1.0.0
commands:
  - name: run
    attributes:
      runType: sequential
    actions:
      - type: exec
        tool: theia-ide
        command: mvn spring-boot:run
        workdir: /projects/petclinic

This would create a petclinic-dev-environment workspace with defined sidecars containers / commands.

[sbose78]

Thanks @ibuziuk , this looks promising.
Are you folks creating a list of devfile samples which we could consult, as part of the learning curve?

[ibuziuk]

@skabashnyuk @mshaposhnik ^ maybe you could comment regarding samples ?

[skabashnyuk]

@ibuziuk the question is a bit unclear. Are we talking about upstream samples or something else?

[ibuziuk]

Are we talking about upstream samples or something else?

yeah, upstream samples

@skabashnyuk AFAIK it is not planned to extend devfile functionality in downstream for osio, so we are planning to fully reuse upstream functionality.

[skabashnyuk]

Are you folks creating a list of devfile samples which we could consult, as part of the learning curve?

In upstream AFAIK no.

[sbose78]

@ibuziuk Could you help us with the API usage for passing the devfile in the payload? Also, would it need changes in che-starter? @tinakurian could get started on that if you could advise on the design.

[ibuziuk]

Could you help us with the API usage for passing the devfile in the payload?

@sbose78 devfile implementation is on early stage currently and not yet merged to master. It will be part of the 6.16 release. Once it will be available on che.openshift.io the API usage should be identical to what I have commented above [1]

Also, would it need changes in che-starter?

Yes, since che-starter, plays the role of API adapter and creation of a workspace based on devfile should go through it.

@tinakurian could get started on that if you could advise on the design.

Implementation should be trivial, but overall design and role of devfile in openshift.io flow is not clear for me currently. Here are the couple of questions we need to answer first before starting any implementation:

• How devfile would be generated for codebase (quickstart / custom repo) ?
• Will it be added to the github repository once codebase is created (I believe the answer is yes here)?
• Will wit pass devfile to che-starter while workspace creation or che-starter should detect devfile in the repository and create workspace according to it (maybe both options should be supported?)

Would be great to understand the whole picture and role of devfile in openshift.io flow instead of starting implementation of the tiny bit of this flow

[1] #4538 (comment)

[sbose78]

How devfile would be generated for codebase (quickstart / custom repo) ?

In the first version, we are gonna use it in boosters ( CRUD specially ). No generation, will create it and place it in the repo.

Will it be added to the github repository once codebase is created (I believe the answer is yes here)?

Yes.
Intially, we'll expect the file to be present in the repo which is being imported.
In version 2,
We'll be showing the user an editable 'template' devfile in the import flow. Subsequently, it would be added to the repo. The import experience hasn't been finalized.

Will wit pass devfile to che-starter while workspace creation or che-starter should detect devfile in the repository and create workspace according to it (maybe both options should be supported?)

Both, if present in repo, use it. Else, if passed as payload, use the one in the payload.

[skabashnyuk]

file to be present in the repo

FYI our implementation will require public GitHub repo.