Describe the bug

docker-compose automatically searches for a compose.yml and an optional, local developer override file compose.override.yml (aka docker-compose.yml and docker-compose.override.yml in earlier versions. From the docs:

Using -f is optional. If not provided, Compose searches the working directory and its parent directories for a compose.yml and a compose.override.yml file. You must supply at least the compose.yml file. If both files exist on the same directory level, Compose combines them into a single configuration.

This flexibility is really useful, especially when debugging problems, or trying out different options as part of iterating on and improving our system.

Our e2e setup hard-codes the main compose config in various helper scripts. This means that it's not practical to override any docker settings locally – to do so, you'd need to hack the helper scripts. Examples:

Proposed improvement

1. Restructure our e2e config so each container uses the default compose filenames.
2. Update the scripts to not explicitly specify the compose file -f – so we get the default behaviour.

This would allow me to use override files to fix the config of the db containers.

Alternatives:

• Map correct user in compose file, so the db container user has enough access (i.e. fix the permissions issue).
• Switch to named volumes everywhere as the new default, stop using volume mount for db (Permission denied issues with mysql data and mounted (docker) volume #3946).
• Add logic to all docker-wrangling scripts to check for an override file, and if found, use it.
• Add a config / environment option to use named volumes, as a supported option for running our environments.

Why I care

I haven't been able to run the e2e environment. The db container dies very soon after launch.

I suspect this is because our default docker setup exposes mysql data (for server and client) as a shared folder. My main development environment uses docker-compose.override.yml to use a named volume instead, which works perfectly for me (and I think it's a more robust approach – I don't think we need to expose the data folder). See related issue for main dev env:

• Permission denied issues with mysql data and mounted (docker) volume #3946

If I could use an override file for all the various WordPress containers needed for e2e, I could specify a named volume instead of a mount, and 🤞 hopefully write and run more e2e tests.