I’m using docker build to compile software and tag the final image, ready to run later.
When the docker build completes successfully the container the build ran in is removed - that seems to be the right thing to do.
When the compile fails and the docker build does not complete then the container is left - that seems to be the wrong thing to do.
Is there a specific reason why the container is left? It seems pointless, but perhaps I’m missing something.
I think this is especially pertinent since ^C during a docker build now stops and removes the container.
$ docker version
Client:
Version: 1.12.0-rc4
API version: 1.24
Go version: go1.6.2
Git commit: e4a0dbc
Built: Wed Jul 13 03:28:51 2016
OS/Arch: darwin/amd64
Experimental: true
Server:
Version: 1.12.0-rc4
API version: 1.24
Go version: go1.6.2
Git commit: e4a0dbc
Built: Wed Jul 13 03:28:51 2016
OS/Arch: linux/amd64
Experimental: true
You appear to be agreeing with the point of my message as a whole - when the build fails the container is left.
I was bringing up ^C during the build because that is a recent change (for the better) demonstrating that user intervention during a build removes the container, so I suggest that failure during a build should remove the container too.
Unless anyone can tell me a good reason why the build container is useful after the build has failed?
in fact Dockerfile is a scenario applied to basic image (in most cases).
when you run “docker build” it perform steps from Dockerfile to basic image , tag container, pack it into the image and delete container.
So if scenario failed - partial image left because of base build process unfinished and tag step as well as other subsequent steps will not performed.
It works same way all time i use docker (from 1.5 or 1.4 as i remember).