-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use anonymous volume for build cache instead of requiring projects to volume mount #31
Comments
In addition to #32, we would want to move npm and composer:
|
Do you see this as being a project specific or global volume that is used? Also, what is your proposed mechanism for automatically mounting it and having it persist between runs? I did some testing with the VOLUME directive in a Dockerfile and while it seems to create the volume doesn't persist between container invocations (at least when I tried using what I think is our typical use case of using the run command). |
@cj does it persist if you remove |
According to this, https://docs.docker.com/engine/reference/run/#clean-up-rm, anon volumes are removed if you use |
Our current handling of this by project per host. The idea there is so any cache issues in one project do not poison other projects. For a global cache solution something like a Squid-based reverse proxy would make more sense. We could also try the approach of a named volume, but that doesn't address #32 and would require more named volume wrangling a la unison. |
I couldn't get it (an anonymous volume) to persist given any combination of up/run and |
@tekante you'd need to add a VOLUMES section in the Dockerfile, then it will persist as long as |
That's what I tried but it doesn't seem to work. Dockerfile used with
docker-compose.yml
I then try |
When I connect your findings to my readings on anonymous volumes, it finally clicked: anonymous volumes are for forensic inspection of container data after crashes or shutdowns. When you restart the container, it makes sense that it would wipe the volume, or generate a new volume ID. Between this behavior and how we would support cache persistence in a cluster environment, it seems clear that we need to go with a more explicitly defined volume -- effectively we need to replace all After playing a little bit with how rig wrangles unison for projects, I don't like the idea of adding more containers external to the docker-compose. So it seems that the main idea here (automatic build cache persistence) is a no-go. |
Many tools use ~/.cache for caching, and many other tools can be configured to do so. Should we automatically support persisting build caches by making this an anonymous volume?
The text was updated successfully, but these errors were encountered: