compose-spec / compose-spec

The Compose specification

Home Page:https://compose-spec.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Extending the behaviour of include to "consolidate" projects instead of merging.

bjconlan opened this issue · comments

What is the problem you're trying to solve
I would like to start 2 projects which share a 'common' compose unit which are shared while using service references

Describe the solution you'd like
Add the as: project field on the import to define that the include isn't to be merged in with the project but run as an isolated unit of infrastructure/network (but can still be used with the 'depends_on' service lifecycle tests)

#common/compose.yml
service:
  db:
#project1/compose.yml
include:
  path: ../common/compose.yml
  as: project
service:
  frontend:
    depends_on:
      - db
#project2/compose.yml
include:
  path: ../common/compose.yml
  as: project
service:
  frontend:
    depends_on:
      - db

So in running $COMPOSE_TOOL -f project1/compose.yml I would basically be doing the following:

# project1/compose.common.yml
service:
  frontend:
    networks:
      - default
      - common

$COMPOSE_TOOL -f common/compose.yml && $COMPOSE_TOOL -f project1/compose.yml -f project1/compose.common.yml

And when running the same for project2 it would result in the 3 compose projects where both project1 and project2 are automatically sharing services exposed in 'common'.

(assumes the network names are the project names (where default releates to 'this' project))

The depends_on behaviour here is a bit of a 'strech-goal' (as there is currently no way to to do this ootb to my knowledge (or this might change the behaviour of how the 'external_links' option works?. In any case this can be solved in the service as is currently done for external service statuses)

Additional context
I have no strong feelings on how this behaviour could be triggered (as: project just seems 'easiest' and a naive suggestion). Its basically just promoting some form of 'inheritance' behaviour but perhaps this complicates things sufficently enough that it's something that can be boiled down to simply having

I actually got this behaviour by just explicitly setting project name (ie added name: x to all projects. This allowed each compose to be stood up in isolation and use any running containers if a dependend/imported compose project service was already running.

Closing this request as I think the workaround is acceptable.