A compose override file that only exists on one machine

docker-compose.override.yml is loaded automatically and is not in version control, which is the point and is also how two developers end up with different stacks.

# docker-compose.override.yml — mine, gitignored
services:
  php:
    volumes:
      - ~/.composer:/home/www-data/.composer
    environment:
      XDEBUG_MODE: debug

# and the thing that made it a problem: somebody's override
# pinned a mysql image tag, so their schema tests passed
# against 8.0.28 and CI ran 8.0.33.

The override file is the right mechanism for personal preferences and the wrong one for anything that affects behaviour. The rule we settled on is that an override may add tooling and may not change an image tag, a port or an environment variable the application reads — and a committed docker-compose.ci.yml covers the cases that need to be shared, explicitly named on the command line so nobody is surprised.