Cleanup for setup_remote_docker Behavior when layer caching is enabled


My assumption here was that we would get a new remote instance which uses an existing docker image cache (that is added to over time by previous builds).

The behavior actually appears to be that the remote docker setup just keeps running in the background, and then your next build connects back to the same instance with all its running containers, named images, volumes, etc.

This means you have a cleanup task and need to manage all state related to running container, but have no way to access it other than running builds?

Right now I am doing this is as the very first step after setup_remote_docker:

- run: docker stop $(docker ps -a -q)
- run: docker rm $(docker ps -a -q)

This works for now, but it seems like this is going to be very difficult to manage if there are more complex issues related to the current state of the docker vm. Being able to connect directly to it might help, but it would be nicer if we could make some assumptions about the state it is going to be in after we run setup_remote_docker


That’s 100% intentional at this time.


Are you thinking of adding a flag to change this behavior? We’d also like to use this feature just of layer caching (as the name implies) - not for recycling containers and volumes…


There are no plans for that at this time.

You can clean them up after each run using when: always under the run directive;