Commands scoped to a project

[benoitf]

Is your feature request related to a problem? Please describe.
When working on multiple projects, we have some commands that are tied to a specific project.

Let say I have a devfile with two projects: one for the backend with java and another for the frontend with javascript.
I might have two containers, one with java/maven and another with nodejs/yarn
Then I can have two commands:

• build-backend
• build-frontend

I can launch them and it will for example either launch maven in the maven container and launch yarn in the nodejs container.

But now inside IDE, we have scoped commands, meaning that if I'm working inside the project backend the task that I see are tied to this project. So for example my debug view contains java debug view, and I want to see only 'build backend' command there. Because 'build frontend' when I'm inside the files of the backend project has no interest there.

Describe the solution you'd like
Add ability to scope a command to a group/project in addition to a component.

Describe alternatives you've considered
N/A

Additional context
UX is not good when you see all commands of the devfile for a specific project as IDE are managing a scope.
We have for example dedicated tasks.json / launch.json files per project.

[sleshchenko]

Does not workDir handle it?

[benoitf]

maybe hijacking workDir might do partially the trick but

Let say I want to start mysql for backend, I don't see how workDir would help
because maybe workDir will be set to /mysql and I will run it inside mysql container.
then I don't see how to map /mysql workdir to be a backend command.

[davidfestal]

After discussing with @benoitf and @l0rd , it seems that adding an optional project field in exec commands would make sense.
It would even have the benefit of enhancing the semantics of the $PROJECT_SOURCE environment variable:

• For now the behavior is defined by this comment:

If there are multiple projects, this will point to the directory of the first one

• If we add the optional project field to a command, this would allow switching to the following behavior:

If the command is associated to a project, this will point to the directory of the associated project, else it will use the directory of the first project in the project list.

@elsony @kadel WDYT of this proposal ? This would be a great thing to have that in Devfile 2.0.0.

[elsony]

I can see the described use case of adding project field to the command especially in an environment like Che where it can be context sensitive to scope the build commands to a given project. Having said that, I think there is going to be some implications as a result this proposal so I think we need more detailed designs on this. In cases like odo which treats the notion of project more loosely than in the Che environment and more focusing on the notion of odo component, i.e. using the devfile more in the context of a stack.

There are a couple of things that we need to be clear in the spec on how we view this project field in the exec command:

1. Is the project field a recommendation or you can only run that build command against that project, e.g. in the odo case, do we error out if someone tries to run that build command against a random odo component?
2. Does tools, e.g. Che, enforces the consistency on the devfile and what's in the Che workspace? For example, if someone creates a workspace based on a given devfile with some projects, they then renamed the project/folder to something else in the workspace. Will it causes the reference of the project to the devfile to become outdated and you can't build that project anymore until the corresponding devfile is modified?
3. If we introduce that, I think we probably need to put some caution on the field in the spec since adding that will make it less portable (if the project field means that command only applies to the given project).

I wonder if it will be more generic to add something like "appliesFor" field to allow quick check on some conditions to see if it applies (action needs to be extremely simple and quick to avoid potential performance impact). For example, what if the original described scenario is one frontend and two backend projects while both backend projects are using maven, then the "appliesFor" check can be checking for the existence of the pom.xml file and the user don't need to clone both the commands for building projects of the same type. And it will provide the devfile writer more flexibility on making their devfile as generic as possible but still allow tools like Che to scope the commands. If the users really need to scope that command to a particular project for some reasons, then the "appliesFor" can also check for specific project name to achieve that.

[elsony]

Based on previous devfile cabal discussions, we will try to limit the simple use case that templating support is used for a single project only (similar to the odo usage). When someone defines multiple projects in a single devfile as a workspace, then the user can write different commands that are specific to each project. We will only update the devfile spec documentation description to clarify that some tools like Che may change the value of the project source location based on the selected project.

[l0rd]

After discussing with @benoitf the requirement has slightly changed as there are cases where a project (a git repo) contains several independent subfolders and a command makes sense only on a particular subfolder (see #385).

Hence we should have something like that:

commands:
  - id: mvn-package
    exec:
      project:                         # <--- optional
        name: quarkus-examples         # <--- mandatory if project is specified
        root: quarkus-backend          # <--- optional
      component: tools
      commandLine: "mvn -Dmaven.repo.local=/home/user/.m2/repository package"
      group:
        kind: build
        isDefault: true

@benoitf please have a look and update the issue description if this correspond to what you have in mind.

[elsony]

Based on the cabal discussion, this setting only applies to specific tools. Therefore, it is not something that should be included as part of the specification. Specific settings that are specific to a particular tool can be achieved by using attributes to define that information. Having said that, we need to make sure those commands will still work with other tools even when attributes are not being interpreted.

[elsony]

Closing this issue since this can be handled by the tools based on the project folder.

[l0rd]

Che-Theia should be able to retrieve information about the root folder to which a command belongs using:

• the command workingdir
• the workspace roots attribute