Skip to content

Client.build and docker build don't share a build cache #998

@SamirTalwar

Description

@SamirTalwar

Copied from docker/compose#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!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions