I wanted to continue a discussion from a bug report here regarding build-time env vars.
I’ve been told that something like this:
build-env
VERSION=stable
Dockerfile
FROM radial/axle-base:latest
ADD build-env /build-env
RUN source build-env && mkdir /$VERSION
RUN ls /
is bad practice for Dockerfiles because it breaks “reproducibility”. But how? Can someone please give me a use case where this is a security problem? What is the downside? The use case here is where someone would like to use the same dockerfile to build from source code, by dynamically, at build time, specify a version to build (which could be pulled, compiled, copied, tagged using this same version info etc.)
The point I was trying to make on the bug report was that what if I’m packaging “build-env” along with my source code in my repo? How is this different conceptually then what I “should” do which is make separate Dockerfiles? It’s specifying a value in a file, and uploading it into the container via build time, it affects the end result which is captured as a docker image with a tag. How is that any different then changing a configuration file for my binary, then rebuilding? This is more of a “templating” use of Dockerfiles, yes, whereby instead of editing my dockerfile manually, or forking it and modifying it, I just do this with a drop-in file at build time.
What is the effective difference between three different Dockerfiles, each with manually selected $VERSION variables, vs. one Dockerfile that uses my hack above to produce 3 different image results? I always thought the reproducibility concern was around doing something like SSH into a running container and tinkering while it’s running rather then how we built the image.
Thanks!
