Ability to inline overrides for included Compose files

[mikesir87]

Description

Feature request - I would like the ability to embed the overrides for an included Compose file without having to write, publish, and maintain another Compose file.

Ideal solution

Taking the example from the include docs that overrides the ports/volumes for included services, I could reduce the usage of multiple Compose files to a single one:

include: 
  - path: ["team-1/compose.yaml"]
    override:
      services:
        service-1:
          ports:
            - 2345:2345
  - path: ["team-2/compose.yaml"]
    override:
      services:
        service-2:
          volumes:
            - ./data:/data

The idea is that the include[].override value is an embedded Compose file.

Why this matters

I'm working on some capabilities in which there will be a base Compose file that will be published and extended to be included in children Compose files. But, they will need to make some changes to it (ports being one of them). Folks will then publish these Compose files and allow others to run it directly.

With the current limitations, authors will need to publish both their final Compose file, as well as the overrides. Or, skip the entire include portion and inline everything.

Having the ability to inline the Compose file streamlines the process by having one less file to publish, version, etc.

[mikesir87]

Another point... I'm not able to publish an overrides file that looks like the following because it isn't a valid compose project (has no image nor a build context):

services:
  service-1:
    # override included service-1 to enable debugger port
    ports:
      - 2345:2345

  service-2:
    # override included service-2 to use local data folder containing test data
    volumes:
      - ./data:/data

[ndeloof]

I also had this in mind, but this would have significant impact on the compose-spec schema and compose-go parser

[ndeloof]

Maybe we could relax import rules and allow use of:

include: 
  - path: ["team-1/compose.yaml"]


services:
  service-1: # actually overrides service-1 from include
    ports:
      - 2345:2345

with current design, this is rejected as services.test conflicts with imported resource, but this is just an initial design decision.

[mikesir87]

this would have significant impact on the compose-spec schema and compose-go parser

I had this same thought. Would definitely complicate things. So, I'm all for finding a simpler solution.

Maybe we could relax import rules

I was running into the same resource conflict issue too. If we could relax those rules, that would certainly unblock me. And, from an authoring perspective, it feels natural to be able to do overrides in this manner.

[ndeloof]

@glours any thoughts ?

[glours]

I’ve already run into this issue on my side several times, and I must admit that if we could simply modify an imported service just by redefining it, that would be great.
However, as with extends, it should be made as explicit as possible to avoid unintended overrides that could end up breaking the entire application.
I wonder if having a dedicated attribute such as override-service, or something like that, in the service definition, would help to provide such feature