`Client.build` and `docker build` don't share a build cache
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 7.2k
- Forks
- 1.7k
- Avg merge
- 13d 8h
- Merged PRs (30d)
- 2
Description
Copied from https://github.com/docker/compose/issues/3148.
I discovered a few days ago that when building images, a cache generated from docker build will not be used by docker-compose build or vice versa. This happens both on my Mac laptop (Docker Machine, Docker v1.10.3 installed through Homebrew) and on an Ubuntu 14.04 server (Docker v1.10.2 installed through apt-get).
Version info for my laptop:
docker-compose version 1.6.2, build unknown
docker-py version: 1.7.2
CPython version: 2.7.10
OpenSSL version: OpenSSL 0.9.8zg 14 July 2015
Version info on my server:
docker-compose version 1.6.2, build 4d72027
docker-py version: 1.7.2
CPython version: 2.7.9
OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
It is simple to reproduce. The directory tiny-app in https://github.com/SamirTalwar/docker-build-weirdness shows the issue:
$ docker build --tag=tiny-app .
Sending build context to Docker daemon 4.096 kB
Step 1 : FROM ruby
---> 0f58cbcb8dce
Step 2 : WORKDIR /app
---> Running in be80cb8a6324
---> 2972973d66d4
Removing intermediate container be80cb8a6324
Step 3 : COPY script ./
---> 77bc9f2b16eb
Removing intermediate container dc9beae186af
Step 4 : CMD ./script
---> Running in ea5f91334ea4
---> d69db9b758e0
Removing intermediate container ea5f91334ea4
Successfully built d69db9b758e0
$ docker-compose build
Building tiny-app
Step 1 : FROM ruby
---> 0f58cbcb8dce
Step 2 : WORKDIR /app
---> Using cache
---> 2972973d66d4
Step 3 : COPY script ./
---> abb5045392d4
Removing intermediate container 1b1450dd66eb
Step 4 : CMD ./script
---> Running in a0c7889ca68a
---> 354c8fcf4876
Removing intermediate container a0c7889ca68a
Successfully built 354c8fcf4876
From the COPY operation onwards, it no longer uses the cache.
I don't know, but I am pretty sure, that this is because the tarballs sent to the Docker server are different. Also in that repo are the uploaded tarballs and hex dumps (hexdump -C), of the same from the CLI and Compose (through docker-py), captured through a fake HTTP server, server.py in the repo. The only real differences seem to be the inclusion of the owner user and group names in the latter, and a flag in the file mode header (grep for 0100644 vs. 0000644) which I cannot find the life of me find documentation on.
I could, of course, be way off. And even if I'm on track, I can't be sure it'll be considered a bug here as opposed to the server.
Whatever the reason, I'd love it if we could reconcile these so the cache is used. Cheers!
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the tiny-app reproduction and server.py, then compare the captured CLI and docker-py tarballs and hexdumps, focusing on owner/group names and file-mode headers. Reproduce docker build followed by docker-compose build, and consider the issue complete when the COPY layer uses the existing build cache in both paths.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, python
- Domain
- api, backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 39/100