Ndtyjky

As my code (nodeJS-application) is changing more often than the (npm) dependencies do, I've tried to build something like a cache in my CI.

I'm using a multi-stage Dockerfile. In that I run npm install for all, and only, prod dependencies. Later they are copied to the final image so that it is much smaller. Great.

Also the build get super fast if no dependency has been changed.

However, over time the hd gets full so I have to run docker prune ... to get the space back. But, when I do this, the cache is gone.

So if I run a prune after each pipeline in my CI, I do not get the 'cache functionality' of the multi-stage Dockerfile.

### 1. Build

FROM node:10.13 AS build

WORKDIR /home/node/app



COPY ./package*.json ./

COPY ./.babelrc ./



RUN npm set progress=false 

    && npm config set depth 0 

    && npm install --only=production --silent 

    && cp -R node_modules prod_node_modules

RUN npm install --silent



COPY ./src ./src

RUN ./node_modules/.bin/babel ./src/ -d ./dist/ --copy-files



### 2. Run

FROM node:10.13-alpine

RUN apk --no-cache add --virtual 

      builds-deps 

      build-base 

      python

WORKDIR /home/node/app



COPY --from=build /home/node/app/prod_node_modules ./node_modules

COPY --from=build /home/node/app/dist .



EXPOSE 3000

ENV NODE_ENV production

CMD ["node", "app.js"]

If your CI system lets you have multiple docker build steps, you could split this into two Dockerfiles.

# Dockerfile.dependencies

# docker build -f Dockerfile.dependencies -t me/dependencies .

FROM node:10.13

...

RUN npm install

# Dockerfile

# docker build -t me/application .

FROM me/dependencies:latest AS build

COPY ./src ./src

RUN ./node_modules/.bin/babel ./src/ -d ./dist/ --copy-files



FROM node:10.13-alpine

...

CMD ["node", "app.js"]

If you do this, then you can delete unused images after each build:

docker image prune

The most recent build of the dependencies image will have a label, so it won't be "dangling" and won't appear in the image listing. On each build its label will get "taken from" the previous build (if it changed) and so this sequence will clean up previous builds. This will also delete the "build" images, though as you note if anything changed to trigger a build it will probably be in the src tree and so forcing a rebuild there is reasonable.

In this specific circumstance, just using the latest tag is appropriate. If the final built images have some more unique tag (based on a version number or timestamp, say) and they're stacking up then you might need to do some more creative filtering of that image list to clean them up.