Dockerfile-created files removed from working directory

[bryanenders]

mutagen version: 0.13.0-beta1
platform: macOS 10.15.7 x86-64

If files or directories are produced by a Dockerfile and there are files for Mutagen to sync, then the Dockerfile-produced directories and files disappear.

To reproduce

1. Add this Dockerfile

# syntax=docker/dockerfile:1
FROM alpine:latest
WORKDIR /code
RUN touch dockerfile-made-me

2. Add this docker-compose.yml

version: "3.9"
services:
  issue:
    build: .
    command: sleep 1d
    volumes:
      - code:/code
volumes:
  code:
x-mutagen:
  sync:
    defaults:
      ignore:
        paths:
          - ".DS_Store"
          - "docker-compose.yml"
          - "Dockerfile"
        vcs: true
      mode: "two-way-resolved"
    issue:
      alpha: .
      beta: "volume://code"

3. Touch mutagen-synced-me
4. Execute $ mutagen compose up --build --detach
5. Execute $ mutagen compose exec issue sh
6. Execute # ls -la

Notice that dockerfile-made-me is missing.

To control

Repeat the above steps, switching the order of 3 and 4. Notice that dockerfile-made-me is present alongside mutagen-synced-me.

[xenoscopic]

The issue at play here is that the volume is mounted into the Mutagen sidecar container before it's mounted into the issue container, so the "new volume" behavior (where volumes inherit container image contents) doesn't occur.

The same issue can be seen with multiple services using Docker Compose (at least w/ V2 where startup order is less predictable):

$ cat Dockerfile
FROM alpine:latest
WORKDIR /code
RUN touch dockerfile-made-me

$ cat Dockerfile2
FROM alpine:latest
WORKDIR /code
RUN touch dockerfile2-made-me

$ cat docker-compose.yml
services:
  issue:
    build: .
    command: sleep 1d
    volumes:
      - code:/code
  issue2:
    build:
      context: .
      dockerfile: Dockerfile2
    command: sleep 1d
    volumes:
      - code:/code
volumes:
  code:

Depending on the startup order, sometimes Dockerfile2's contents will be present in the volume and sometimes Dockerfile's contents will be present in the volume. In the Mutagen case, it will always be whatever Mutagen is synchronizing since it will have the volume mounted first.

I'm not sure how often the volume-inheriting-image-contents is relied upon in the wild, at least when it comes to Compose. If it's something really common, perhaps we can come up with a workaround, but I don't have one at the moment.

The best thing would probably just be to document this behavior. Would that be sufficient?

[bryanenders]

Thanks for this thorough explanation, Jacob. I agree that documenting the behavior would be just the thing.

[xenoscopic]

I've added a note on this issue to the Mutagen Compose documentation, so I think we can close this out.