The commands in project samples are not compatible with commands in devfile format

[ashumilova]

The commands, that are listed in project samples, have the following format

"commands": [
      {
        "name": "build and run",
        "type": "custom",
        "commandLine": "cd ${current.project.path} \ngcc -o Hello Hello.c \n./Hello",
        "attributes": {
          "previewUrl": "",
          "goal": "Run"
        }
      }
    ]

and are added to workspace along with the projects by dashboard.
The format of those commands works fine with workspace config and is not compatible with devfile format. This can be fixed on the application side - like converting from one format to another. But there is one problem - setting the commands required field - component(where to be executed), on this stage it's not clear.
In devfile command format:

commands:
  - name: build
    actions:
      - type: exec
        component: petclinic
        command: './mvnw package'
        workdir: /projects/spring-petclinic

[sleshchenko]

Let me highlight possible ways to move forward here:

1. Make component in devfile actions optional, and then UD would be able to convert commands from Projects samples to Devfile commands, user would be asked to pick containers during the launching of a command.
   In general, I think it makes sense to make the component field optional, for example, there may be some abstract commands and user may need to choose containers where it should be executed. For example Show processes | ps aux, this case is theoretical and I have no idea why user may need such command in Devfile but still, such case is possible.
   Then Create Workspace workflow will work in the same way as we used to see it, choose stack, choose projects from samples or provides your own.
   After that, we can iteratively rethink/rework Projects Samples to be consistent with Devfile format and avoid such workaround with converting old commands format to new on UD side.

2. Ignore commands from Projects Samples and during Workspace creation flow inject only projects sources into Devfile chosen from Devfile Registry.
   Then again we can iteratively rethink/rework Projects templates and will see if we still need commands and how they should look like.

3. Do not try to use outdated Projects Samples in new Workspace creation flow (allow a user to add project only by specifying git repo URL but not choosing it from samples list).
   Rethink and introduce new Projects Samples API, that is consistent with Devfile format.

@l0rd @slemeur I remember there were some discussions about the future of Projects Samples but I do not remember the conclusion. Can you remind it if it exists and leave your opinions about proposed ways?

[l0rd]

What about adding a new component attribute in the legacy samples commands that would be then matched with one of the devfile components?

"commands": [
      {
        "name": "build and run",
        "type": "custom",
        "commandLine": "cd ${current.project.path} \ngcc -o Hello Hello.c \n./Hello",
        "attributes": {
          "component": "petclinic",
          "previewUrl": "",
          "goal": "Run"
        }
      }
    ]

[l0rd]

@ashumilova @sleshchenko we can embed the sample (project and commands) in the devfiles as well. I thought about doing it after GA but if you think that's simpler let's do that right now.

[sleshchenko]

What about adding a new component attribute in the legacy samples commands that would be then matched with one of the devfile components?

"commands": [
      {
        "name": "build and run",
        "type": "custom",
     "commandLine": "cd ${current.project.path} \ngcc -o Hello Hello.c \n./Hello",
        "attributes": {
          "component": "petclinic",
          "previewUrl": "",
          "goal": "Run"
        }
      }
    ]

petclinic is a project name but not component. Probably peclinic sample can be used on java-maven or java-gradle devfiles and they have different components - maven and gradle in accordance.
I think it would be a tricky workaround since we would have a soft reference from sample to devfile and there is no any guarantee that it won't be broker someday, like component won't be renamed.

@ashumilova @sleshchenko we can embed the sample (project and commands) in the devfiles as well. I thought about doing it after GA but if you think that's simpler let's do that right now.

Do you mean that devfile registry will contain actually samples for Devfiles, but not stacks for technologies? And then dashboard may allow user to override sample project and try to use devfile with user's project?
If we have two sample projects for one devfile(I mean set of components), then devfile in devfile registry should be duplicated or contain everything for two projects? Like java devfile and samples - java hello worlds and petclinic.

[l0rd]

petclinic is a project name but not component.

@sleshchenko I took the petclinic component from the devfile example in the issue description.

Probably peclinic sample can be used on java-maven or java-gradle devfiles and they have different components - maven and gradle in accordance.
I think it would be a tricky workaround since we would have a soft reference from sample to devfile and there is no any guarantee that it won't be broker someday, like component won't be renamed.

Yes we need to change the alias of the components in the devfiles: it's fragile and not ideal. Another option is to duplicate samples. For example java-console-simple will be duplicated twice for java-gradle and java-maven but will have different commands.

I have created an issue for the other proposal #13529 but I don't think that we can make it for GA so I am -1 for that one.

About your 3 proposals:
'1) is the one I prefer but it's just a temporary workaround. I am not sure we need a command without a target component. And adding another click in the user workflow is annoying and error prone.
'2) '3) not being able to define commands (and projects) for the stacks removes too much value for the user so -1 for those as well

[sleshchenko]

is closed in favor of #13529