Unexpected behaviour when running 2 docker compose in different paths

[dferendo]

Expected Behaviour

This works in command line, it runs the 2 compose files:

  try {
    execSync(
      'docker compose -f ../lib/rollup/docker/docker-compose.yml -f docker-compose.yml up -d',
      {
        cwd: path.resolve(PROJECT_ROOT, "docker"),
        stdio: 'inherit'
      }
    );
  } catch (error) {
    console.error("Docker compose failed:", error);
    throw error;
  }

Running it with the library using

  environment = await new DockerComposeEnvironment(
    dockerDir,
    ["../lib/rollup/docker/docker-compose.yml", "docker-compose.yml"]
  )
  .withBuild()
  .up();

gives the error open docker.ignition.Dockerfile: no such file or directory

Actual Behaviour

docker compose -f ../lib/rollup/docker/docker-compose.yml -f docker-compose.yml up

Library should follow the cli commands, but maybe i missed something

Testcontainer Logs

      at handleAndRethrow (node_modules/.pnpm/testcontainers@10.21.0/node_modules/testcontainers/src/container-runtime/clients/compose/compose-client.ts:214:46)
      at ComposeV2Client.up (node_modules/.pnpm/testcontainers@10.21.0/node_modules/testcontainers/src/container-runtime/clients/compose/compose-client.ts:136:13)
      at async DockerComposeEnvironment.up (node_modules/.pnpm/testcontainers@10.21.0/node_modules/testcontainers/src/docker-compose-environment/docker-compose-environment.ts:110:5)
      at async startEnvironment (e2e/util/containers.ts:37:17)
      at async Context.<anonymous> (e2e/util/testWithContainers.ts:9:5)

Steps to Reproduce
2 docker compose in different folders

Environment Information

• Operating System: macos
• Docker Version: 28.0.1
• Node version: v22.14.0
• Testcontainers version: 10.17.2

[cristianrgreco]

The Testcontainers API isn't meant to 100% mirror the CLI, otherwise there wouldn't be much point in it. The first arg to DockerComposeEnvironment allows you to define where your compose files are, and the second arg let's you provide the names of the compose files. It does not mix and match.

To achieve what you want you could do something like:

  environment = await new DockerComposeEnvironment(
    __dirname,
    ["./path/to/file1", "./path/to/file2"]
  )
  .withBuild()
  .up();

[dferendo]

So you always need to have the docker compose files in the same directory for it to work?

I think it's useful if you can specify different paths to build more complex testcases, in my environment I have a docker compose file in a git submodule which I add more containers to it using another docker compose file from my repository

[cristianrgreco]

So you always need to have the docker compose files in the same directory for it to work?

No, have a look again at my example where I provide compose files in different paths relative to __dirname. Replace __dirname with whatever makes sense

[dferendo]

i already did as mentioned in the issue itself

  const environment = await new DockerComposeEnvironment(
    PROJECT_ROOT,
    ["./lib/rollup/docker/docker-compose.yml", "./docker/docker-compose.yml"]
  )
  .withBuild()
  .up();

which gives the error failed to solve: failed to read dockerfile: open docker.ethereum.Dockerfile: no such file or directory. it works fine using a single docker compose which is why im leaning it being more of a bug i think

[cristianrgreco]

Gotcha - where is docker.ethereum.Dockerfile relative to PROJECT_ROOT? Could you share where this file is being referenced in the (I assume) docker-compose files?

[dferendo]

PROJECT_ROOT/
├── docker/
│   ├── docker-compose.yml
│   ├── docker.ethereum.Dockerfile
│   └── docker.ignition.Dockerfile
│
└── lib/
    └── rollup/
        └── docker/
            ├── fuel_committer/
            ├── fuel_node/
            ├── sequencer/
            ├── docker-compose.yml
            ├── docker.eth_node.Dockerfile
            ├── docker.fuel_committer.Dockerfile
            ├── docker.fuel_node.Dockerfile
            └── docker.sequencer.Dockerfile

In the application, i run lib/rollup/docker/docker-compose.yml first and then docker/docker-compose.yml, which is dependent on the first compose. The docker compose both work fine if using the cli. They also work fine if using a single docker compose and testcontainers