Decking build creates no-name images

[frostyandy2k]

Hi
First of all, thanks for this nifty tool, it's great!
I have an issue while building my images with decking. No name or tag is assigned to the image. If I build them manually using the docker command line it works fine and I can create and start my cluster with decking.

decking build all --no-cache

REPOSITORY                    TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
<none>                        <none>              9dafa7533412        24 seconds ago      840.8 MB

Using boot2docker on OSX 10.9
image declaration in docking.json:

"images": {
    "instaguide/wizard-api": "../../wizard-api"
}

Output:

Looking up build data for instaguide/wizard-api
Building image instaguide/wizard-api from ../../wizard-api/Dockerfile
Uploading compressed context...

[stevepacker]

I am experiencing the same on

• OSX 10.10.1
• Boot2Docker-cli version: v1.3.2 (Git commit: a830982)
• Docker version: 1.3.2 (Git commit: 39fa2fa)

[frostyandy2k]

Tried it out on another machine, Ubuntu 14.04. The same thing but instead of creating multiple -name images I get only one, although it tells me the build are run for for all my 5 images.
So it's not a boot2docker issue.

Maybe it's an issue with the underlying 'dockerode' module?

[makeusabrew]

Hi both,

Sorry for the radio silence. I'll try and take a look at this soon.

[makeusabrew]

Tried replicating this on Ubuntu 14.10; not seeing it when building either a single image by name (e.g. decking build foo/bar) or all (decking build all).

I know the output is likely extremely long and tedious but I'd be interested in seeing it in either of your cases @frostyandy2k or @stevepacker? I suspect the build process itself is erroring somewhere leaving a dangling image.

[frostyandy2k]

Hi @makeusabrew, thank you for looking into it.

$ decking build instaguide/reactor
Looking up build data for instaguide/reactor
Building image instaguide/reactor from ./../../reactor/Dockerfile
Uploading compressed context...
Step 0 : FROM node:0.10-onbuild
# Executing 3 build triggers
Trigger 0, COPY package.json /usr/src/app/
Step 0 : COPY package.json /usr/src/app/

$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
node                0.10-onbuild        2818a8b74c64        6 days ago          696 MB

If I build it with "docker build" I get the following output. As you can see, the image i wanted to build does not appear in the image list when I use decking:

$ docker build -t instaguide/reactor .
Sending build context to Docker daemon 30.57 MB
Sending build context to Docker daemon 
Step 0 : FROM node:0.10-onbuild
# Executing 3 build triggers
Trigger 0, COPY package.json /usr/src/app/
Step 0 : COPY package.json /usr/src/app/
Trigger 1, RUN npm install
Step 0 : RUN npm install
 ---> Running in 834b848f5c05
npm WARN package.json reactor@1.0.0 No description
npm WARN package.json reactor@1.0.0 No repository field.
npm WARN package.json reactor@1.0.0 No README data

> contextify@0.1.13 install /usr/src/app/node_modules/jest-cli/node_modules/jsdom/node_modules/contextify
> node-gyp rebuild

make: Entering directory '/usr/src/app/node_modules/jest-cli/node_modules/jsdom/node_modules/contextify/build'
  CXX(target) Release/obj.target/contextify/src/contextify.o
  SOLINK_MODULE(target) Release/obj.target/contextify.node
  SOLINK_MODULE(target) Release/obj.target/contextify.node: Finished
  COPY Release/contextify.node
make: Leaving directory '/usr/src/app/node_modules/jest-cli/node_modules/jsdom/node_modules/contextify/build'
traits@0.4.0 node_modules/traits

underscore@1.7.0 node_modules/underscore

morgan@1.5.1 node_modules/morgan
├── basic-auth@1.0.0
├── depd@1.0.0

[other npm output ...]

Trigger 2, COPY . /usr/src/app
Step 0 : COPY . /usr/src/app
 ---> 63213e3ac30b
Removing intermediate container 25c01d859718
Removing intermediate container 834b848f5c05
Removing intermediate container 63bfd6ed9ea0
Step 1 : RUN npm install supervisor -g
 ---> Running in 54c72a603cad
/usr/local/bin/node-supervisor -> /usr/local/lib/node_modules/supervisor/lib/cli-wrapper.js
/usr/local/bin/supervisor -> /usr/local/lib/node_modules/supervisor/lib/cli-wrapper.js
supervisor@0.6.0 /usr/local/lib/node_modules/supervisor
 ---> b6fad00d4f27
Removing intermediate container 54c72a603cad
Step 2 : EXPOSE 4000
 ---> Running in d2d12bceb802
 ---> b7b413ae76a2
Removing intermediate container d2d12bceb802
Step 3 : CMD npm start
 ---> Running in 2a1dfc24fcf0
 ---> 15c92a84d8ed
Removing intermediate container 2a1dfc24fcf0
Successfully built 15c92a84d8ed

$ docker images
REPOSITORY           TAG                 IMAGE ID            CREATED              VIRTUAL SIZE
instaguide/reactor   latest              15c92a84d8ed        About a minute ago   761.8 MB
node                 0.10-onbuild        2818a8b74c64        6 days ago           696 MB

[makeusabrew]

Hi both,

Turns out this is actually caused by the docker build command failing at some point during the build process. Docker returns the output as a stream but without extra effort it doesn't explicitly let us know about any build errors. As such decking was silently swallowing these errors, not reporting them, and not going on to create the final image. The "no name" images referenced in the original ticket are actually just docker's intermediate containers which haven't been cleaned up.

@frostyandy2k's latest snippet demonstrates this clearly. The decking output stops after the very first step.

I suspect you're both receiving these silent errors because of the same reason - you probably have ADD paths in your Dockerfile local to where it physically sits. Decking copies the Dockerfile into the same directory as decking.json / decking.yaml during build so those ADD paths probably don't exist when using decking.

I appreciate this behaviour is non-obvious but it's something which has been in place since day one as decking was originally just a tool to scratch an itch, and my use case at the time required building lots of different images all from subdirectories in the same repo which was at odds with Docker's restrictive 'context' logic around ADD commands. I'll revisit this soon and assess the current state of play as I know Docker has moved on a lot since the old days (~ October 2013).

For what it's worth, the next version of decking which I'll publish this week will at least report these errors properly.

[frostyandy2k]

Hi @makeusabrew, thank you a lot for having a look at this.
I was not aware of the copying process within that context, should have read the docs more careful...

Thank you again, looking forward to the new decking version.
Keep up the good work!