Hacker News Reader

Comment by Ajedi32 | Hacker News Reader

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

Buried deep somewhere in the code.

But yeah I don't see any reason why you couldn't theoretically make a reproducible build with Docker.

View on HN

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.

Or if you change anything that comes before that line.

Reply on news.ycombinator.com