Command group (application lifecycle)

[kadel]

Commands should have a group field that will specify in what point of application lifecycle the command should be executed (or type of the command like, build, incremental-build, run etc..).

• group field is optional
• Many commands of the same devfile can belong to the same group
• Only one command belonging to a group can be the default
• The list of groups should be: build, run, test, debug

commands:
 - exec:
     name: "package"
     commandLine: "mvn package"
     component: build-tools
     group: 
        kind: build
 - exec:
     name: "install"
     commandLine: "mvn install"
     component: build-tools
     group: 
         kind: build
         isDefault: true 

[gorkem]

For reference vscode uses group instead of type.

[davidfestal]

I also prefer group instead of type, because it seems that type name is a bit confusing due to its frequent use in the context of sub-typing, or polymorphism.

Here we're more thinking of partitioning / grouping Exec commands into several categories, which is why I like the group (or category) field name better.

[kadel]

Here we're more thinking of partitioning / grouping Exec commands into several categories, which is why I like the group (or category) field name better.

Completely agree. group or category is far better than type which is already overloaded term.

[l0rd]

We reviewed this proposal and agreed on the following specs:

• We should use group instead of type for this proposal
• group field is optional
• Many commands of the same devfile can belong to the same group
• Only one command belonging to a group can be the default

We started discussing whether we should have or not a default command for a given group like

commands:
 - exec:
     name: "package"
     commandLine: "mvn package"
     component: build-tools
     group: 
        name: build
 - exec:
     name: "install"
     commandLine: "mvn install"
     component: build-tools
     group: 
         name: build
         isDefault: true 

or

commands:
 - exec:
     name: "package"
     commandLine: "mvn package"
     component: build-tools
     group: build
 - exec:
     name: "install"
     commandLine: "mvn install"
     component: build-tools
     group: build
 - groupsDefaults:
     - group: "build"
       command: "install" 

or

commands:
 - exec:
     name: "package"
     commandLine: "mvn package"
     component: build-tools
     group: build
 - exec:
     name: "install"
     commandLine: "mvn install"
     component: build-tools
     group: build
 - groupsDefaults:
     - build: "install" 

[gorkem]

Is there a list of recognized 'group's?

[l0rd]

@gorkem we haven't discussed that but haven't finished to discuss this issue. We will continue next week.

[davidfestal]

I assume that, in the second example proposed in comment #27 (comment), adding a single groupDefaults element at the end of the list of commands would not be very easy to define, both in Go and in the derived JSON schema, since it's a completely different schema, and not really a Command.
Additionally afaik enforcing it to appear only once through the schema validation might be impossible at this location.

commands:
 - exec:
     name: "package"
     commandLine: "mvn package"
     component: build-tools
     type: build
 - exec:
     name: "install"
     commandLine: "mvn install"
     component: build-tools
     type: build
 - groupsDefaults:
     - group: "build"
       command: "install" 

[l0rd]

Discussed and agreed

[groeges]

Is there any way to define different commandLines dependant on which Operating System is being used, specifically for group: "init" (or group: "initLocal") which will be run on the users local system?

[l0rd]

@groeges given that the commands are supposed to be executed in a container (components are k8s/openshift/container objects) and not as a local processes, supporting multiple OSes doesn't look like a valid use case.

[groeges]

@l0rd I agree that most of the commands will be running within the container so a single script is OK, however I thought there was a devInitLocal being added (or something like that) which will run a command to initialise the project on the users local workspace and this is the case that may need to have multiple commandLines based on OS. If this is not being added then this is not an issue, but otherwise it is.

[l0rd]

@groeges we are discussing that in #30 but I consider that devfiles describe container-based development workspaces and making it suitable for local dev (i.e. running local processes, accessing local files) is out of scope. But we can discuss that.

[davidfestal]

Implemented