Dependencies should use same profile as parent

[verenion]

We currently have DevSpace setup in such a way that allows us to have one single project with a devspace.yaml file with mostly a list of dependencies. This project represents our entire stack, which can then be deployed in different environments (local, staging, production, etc). Each of these dependencies also have a devspace.yaml file and they define the helm charts and hooks for each of our apps. Some of these application also have dependencies too. So our final "project structure" looks something like this:

• DevSpace
  • API
  • Service1
    • Service3
  • Service2

This works great for development and testing, as this allows our entire stack to be deployed and configured in one simple command (devspace deploy), but we have recently run into a problem with deploying to production (using profiles).

My plan originally was to simply run devspace deploy -p production on the root project, to allow the entire "stack" to be deployed in one go. Each project will have a "production" profile for it's own specific configuration. My assumption was that dependencies use the same profile as the "parent". In my example above, this would mean that DevSpace, API, Service1, Service2 and Service3 are all deployed with the "production" profile.

However, that doesn't seem to be the case, which I find rather surprising. This means I'm having to define my dependencies like this:

  - name: api
    source:
      git: ...
      branch: ...
    profile: ${devspace.profile}

  - name: service1
    source:
      git: ...
      branch: ...
    profile: ${devspace.profile}

  ...

Which solution do you suggest? My suggestion would be that if a profile is used to deploy a project, all dependencies of that project are also deployed using the same profile.

Which alternative solutions exist? I've looked through the documentation and come across various mechanisms for profiles, but none seem to solve this specific issue. (Although, I might well be missing something obvious)

https://devspace.sh/cli/docs/next/configuration/profiles/parents - seems to be more for chaining profiles, as opposed to the hierarchy of profiles https://devspace.sh/cli/docs/next/configuration/profiles/basics - States: "Permanently switching to a profile means that all future commands (e.g. devspace deploy or devspace dev) will be executed using this profile until the user resets the profile". Again, this seems ambiguous, as dependencies are not currently using the same profile as the parent.

I also haven't really looked at the alpha release, but as we are planning to use this in production, we would like to wait until a more stable release is formed - although, it would be nice to know if using the new pipelines feature would help solve this.

Additional context

/kind feature

[timofriedlberlin]

This concept would only work under the assumption that profiles are named consistently accross dependencies. I dont think this is a valid assumption. In our company at least profiles are very lose and share no conceptional naming convention accross dependencies. Also i think if you would do it this way you create a dependency/linkage via fixed set of profile names accross those projects which should not exist.

What I do to solve this is simply using patches in profile of Project A to modify the dependency to Project B.

If A.profile==production use B.profile==foobar

I find this approach flexible enough.