[question] Sharing ~/.conan/data among Docker containers
See original GitHub issueWe’re going to use Docker containers to provide stable build environments for C++ projects. Third party dependencies are pre-built and packaged into Conan packages. I’d like to share Conan cache among containers in order not to download packages each time new container is started. But I don’t want to share Conan settings (profiles, remotes, etc.) as it’s a part of build environment.
Is it possible/safe to share ~/.conan/data
among multiple containers having different Conan settings in ~/.conan
?
- I’ve read the CONTRIBUTING guide.
Issue Analytics
- State:
- Created 2 years ago
- Comments:6 (3 by maintainers)
Top Results From Across the Web
How to access private conan repository when using docker?
Description of Problem, Request, or Question I'm trying to build a package ... and the remote in docker container seems remain 'anonymous':.
Read more >Error executing a cmake project with Conan dependencies ...
I'm trying to run a cmake project using conan as a package manager where the project is compiled in a docker container.
Read more >Plex Docker - Unraid 6.5 - VAAPI problem
Hello, I have Binhex-Plexpass installed and got HW transcoding working with plex, but i get this errors when a user tries to play...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
A note @czoido, concurrency will only be limited to same computer concurrency. All the synchronization mechanisms that we can use (with a reasonable approach), only works for the same machine (semaphores, mutexes, file locking… only works at the machine level, not inter machine). So anything that means that the same cache is shared among different containers will not be concurrent safe.
Assuming there is perfect and exclusive sequential access to the cache, in the current cache, yes, there could also be issues (different machines continuoesly overwriting the same package with different revisions, as the cache can only store 1 revision). With the new 2.0 cache, that uses revisions, this might not happen. But the concurrency hypothesis must hold in practice, and I guess it is unlikely to always hold (for CI, almost impossible, for developer boxes, like a developer is not going to switch to another container to test something while the other container is building other thing in the same shared cache…)
Yes, we are exploring other synchronization mechanisms besides fasteners for 2.0. We might keep with fasteners, but this is unknown atm.