Cleaning Intermediate images & Flag "noprune-rmi" having no effect
dduportal opened this issue · 2 comments
Hello!
I am using habitus to build a collection of docker images co-located on a single repository.
Some depends on others (as "dind-base" -> "devbox"), and we may have 2 nested levels ("java-base" -> "jenkins-base" -> "jenkins-custom").
I discovered that all the intermediate "parent" images are cleaned up at the end of the habitus build.,
even if they are specified by the build.yml
file.
=> As a User, I don't understand this behavior by default.
However, reading the documentation on the page "habitus.io", I saw the following:
noprune-rmi: Doesn't prune unwanted images after the build
So I tried it, but my images are still deleted.
Am I missing something, or is it a bug?
- A simplified
build.yml
file for reproduction:
# Habitus build file
build:
version: 2016-03-14 # version of the build schema.
steps:
dind-base:
name: dind-base
context: ./dind-base
dockerfile: Dockerfile
devbox:
name: devbox
context: ./devbox
dockerfile: Dockerfile
depends_on:
- dind-base
Dockerfiles:
# dind-base/Dockerfile
FROM alpine:3.7
RUN echo FOO > /foo.txt
# devbox/Dockerfile
FROM dind-base
RUN cat /foo.txt > /bar.txt
Here is the execution command (and log):
habitus -noprune-rmi
2018/05/29 09:48:31 ▶ Using '/Users/dadou/workspace/cloudbees/training-docker-library/tmp/build.yml' as build file
2018/05/29 09:48:31 ▶ Collecting artifact information
2018/05/29 09:48:31 ▶ Building 2 steps
2018/05/29 09:48:31 ▶ Step 1 - dind-base, image-name = 'dind-base'
2018/05/29 09:48:31 ▶ Step 2 - devbox, image-name = 'devbox'
2018/05/29 09:48:31 ▶ Step 1 - Build for dind-base
2018/05/29 09:48:31 ▶ Step 1 - Building dind-base from context '/Users/dadou/workspace/cloudbees/training-docker-library/tmp/dind-base'
2018/05/29 09:48:31 ▶ Step 1 - Parsing and converting 'Dockerfile'
2018/05/29 09:48:31 ▶ Step 1 - Writing the new Dockerfile into '/Users/dadou/workspace/cloudbees/training-docker-library/tmp/dind-base/Dockerfile.generated'
2018/05/29 09:48:31 ▶ Step 1 - Building the dind-base image from /Users/dadou/workspace/cloudbees/training-docker-library/tmp/dind-base/Dockerfile.generated
Step 1/2 : FROM alpine:3.7
3.7: Pulling from library/alpine
ff3a5c916c92: Already exists
Digest: sha256:7df6db5aa61ae9480f52f0b3a06a140ab98d427f86d8d5de0bedab9b8df6b1c0
Status: Downloaded newer image for alpine:3.7
---> 3fd9065eaf02
Step 2/2 : RUN echo FOO > /foo.txt
---> Running in a44978de8534
Removing intermediate container a44978de8534
---> d4647da426aa
Successfully built d4647da426aa
Successfully tagged dind-base:latest
2018/05/29 09:48:35 ▶ Step 2 - Build for devbox
2018/05/29 09:48:35 ▶ Step 2 - Building devbox from context '/Users/dadou/workspace/cloudbees/training-docker-library/tmp/devbox'
2018/05/29 09:48:35 ▶ Step 2 - Parsing and converting 'Dockerfile'
2018/05/29 09:48:35 ▶ Step 2 - Writing the new Dockerfile into '/Users/dadou/workspace/cloudbees/training-docker-library/tmp/devbox/Dockerfile.generated'
2018/05/29 09:48:35 ▶ Step 2 - Building the devbox image from /Users/dadou/workspace/cloudbees/training-docker-library/tmp/devbox/Dockerfile.generated
Step 1/2 : FROM dind-base
---> d4647da426aa
Step 2/2 : RUN cat /foo.txt > /bar.txt
---> Running in 744ba5f31949
Removing intermediate container 744ba5f31949
---> 31121503c301
Successfully built 31121503c301
Successfully tagged devbox:latest
2018/05/29 09:48:36 ▶ Step 1 - Removing unwanted image dind-base
=> It ends with Step 1 - Removing unwanted image dind-base
For information, using the flag -keep-all
has the intented behavior.
What did I miss ?
@dduportal Hi, thanks for using habitus 😄
-noprune-rmi
corresponds to docker's noprune
, which affects untagged parent images of dind-base
in this case. Probably this part of the official docker doc and habitus' code would help understanding this behavior.
To summarize, you need -keep-all
to retain dind-base
. Otherwise it is removed along with all the untagged parent images of dind-base
. noprune-rmi
keeps untagged parent images, but not dind-base
itself.
Does this clarifies things enough? Perhaps we need to improve docs and/or log messages? Any input is welcomed. Thanks!
Closing for lack of activity