Running the same script every time doesn't necessarily guarantee the same result.
Lots of docker build scripts have the equivalent of
date > file.txt
curl https://www.random.org/integers/?num=1&min=1&max=1000&col=1&base=10&format=plain&rnd=new > file.txt
But yeah I don't see any reason why you couldn't theoretically make a reproducible build with Docker.
Docker images actually contain the timestamp each layer was built at, so are basically de-facto non-reproducible.
Buildah from Red Hat has an argument to set this programmatically instead of using the current date, but AFAIK there's no way to do that with plain old docker build.
The nixpkgs workaround is to build images with build-date == 1970-01-01. Annoying but reproducible.
If you have dynamism like this in your build, doesn't that imply that no build system is reproducible?
My point was just that Docker doesn't ensure reproducibility. Whether a build is reproducible or not depends on the steps used, so its possible but not "ensured".
If you wanted to guarantee reproducibility, a hypothetical purely-functional build system could do that. I personally don't think that's necessary though, or that it would be worth the requisite trade-offs.
Yes, but previous commenter said
> I [thought] Dockerfile ensured that builds are indeed reproducible?
The example straightforwardly disproves that.
Would that not be cached? It would not actually run that date command again, right? unless you change that date line itself, in the Dockerfile.
If you’re using a cached version, you haven’t really reproduced anything but the cache itself. Reproducibility means creating the same output given the same input, every time, regardless of some local cache.
That said, the above example isn’t specific to Docker.
I though Dockerfile ensured that builds are indeed reproducible?