Dependent Projects

[l0rd]

Which area this feature is related to?

/area api

Which functionality do you think we should add?

Introduce a new field, dependentProjects in the Devfile spec.

Why is this needed? Is your feature request related to a problem?

The devfile is supposed to be versioned in the application git repository and there is no need to specify the project (repo and revision) as that's implicit.

To support multi-project workspaces we want to introduce a new field, dependentProjects in the Devfile spec. That would allow cloning repositories other than the one where the devfile is located.

Detailed description:

The sample

The .devfile.yaml in the backend git repository:

schemaVersion: 2.2.0
metadata:
  name: backend
dependentProjects:
  - name: frontend
    git:
      remotes:
        origin: https://github.com/myorg/frontend.git
      checkoutFrom:
        revision: main
components:
  - name: devtools
    container:
      (...)  

This is the devfile of the backend service and it references the frontend repo using the dependentProjects field. As a result the source code of the frontend will be included in the cloud development environment:

The resulting folders

All git repositories get cloned in $PROJECTS_ROOT. The current project source code, with the devfile defining the dev environment, is cloned in $PROJECT_SOURCE.

$PROJECTS_ROOT   
  ├── backend                 # <== corresponds to $PROJECT_SOURCE
  │     │
  │     ├── .devfile.yaml
  │     ├── .git
  │     └── (...)                 
  └── frontend
        │
        ├── .devfile.yaml    # <== the dependent project might have a devfile but it's
        │                    #     ignored because the current project is "backend" 
        ├── .git
        └── (...) 

Commands can target a dependent project

The devfile in my backend git repository can include commands to build/run/debug the frontend too:

schemaVersion: 2.2.0
metadata:
  name: backend
dependentProjects:
  - name: frontend
     (...)
components:
  - name: devtools
     (...)
commands:
  - id: run-backend
    exec:
      commandLine: <command to run the backend>  # <== the default workingDir is $PROJECT_SOURCE
  - id: run-frontend
    exec:
      workingDir: ${PROJECTS_ROOT}/frontend      # <== this command workingDir is where the 
      commandLine: <command to run the frontend> #     frontend project is cloned
      component: devtools

[l0rd]

@elsony @kadel I have updated this issue description with some details about:

• the folders where the projects will be cloned
• the (optional) dependentProjects devfiles that will be ignored
• devfile commands can target a dependentProjects

[kadel]

Introducing depdendatProjects into devfile will just create problems and a lot o complications without much benefit.

The fundamental problem for me is that it creates a false sense o hierarchy.
In the example, the frontend is defined as a dependent project inside backend devfile.
But the file structure doesn't reflect this nesting (I'm definitely not saying that we should clone the frontend into the backend directory).

Another big problem I see is ignoring devfile from the dependent projects. Yes, it will make implementation more straightforward, but as a user, I would find that surprising, and I would consider that a bug.

I'm not convinced that this is something that should be in Devfile. The devfile should stay scoped to a single project. The decision to remove projects and essentially limit the devfile to the current repository or directory is good and takes Devfile in the right direction. But introducing depedantProjects is introducing all the problems we see with projects back.

If we want to allow users to work with multiple projects at the same time, it should be tooling that makes that possible, we don't need anything special in devfile spec. For example, in VSCode I can add multiple folders to the workspace. If we can import two Devfile projects into the workspace in Che I would consider that a far more elegant solution than this.

[cgruver]

@kadel What is the rational for removing projects from the devfile? IMO this would be a step backward for developer onboarding to Eclipse Che / Dev Spaces.

Most of the enterprise development teams that I have worked with are on projects with multiple repos that comprise the "Application".

Having the ability to automate the cloning of multiple repositories into a workspace greatly improves the onboarding experience for team members.

I have a really lame app example here: https://github.com/eclipse-che-demo-app/che-demo-app

[kadel]

After discussing this issue with @l0rd I understand the rationale behind this change.
It is not going to have a significant impact on the Devfile spec. It is a completely new field, but there is only one change compared to how projects work today, and that is the implicit current project.

[michael-valdron]

Since this being worked on by Eclipse Che Team, I will remove from Devfile Project tracking.