[ricardobeat]

> so two docker builds can end up with the same hash but different output

The cache key includes the state of the filesystem so I don’t think that would ever be true.

Regardless, the purpose of the tool is to generate [layer] images to be reused, exactly to avoid the pitfalls of reproducible builds, isn’t it? In the context of the article, what makes builds reproducible is the shared cache.

[xyzzy_plugh]

It's not reproducible then, it's simply cached. It's a valid approach but there's tradeoffs of course.

[verdverm]

it's not an either or, it can be reproducible and cached

similarly, nix cannot guarantee reproducibility if the user does things to break that possibility

[xyzzy_plugh]

The difference is that you can blow the Nix cache away and reproduce it entirely. The same cannot be said for Docker.

[verdverm]

That's not true

Docker has a `--no-cache` flag, even easier than blowing it away, which you can also do with several built in commands or a rm -rf /var/lib/docker

Perhaps worth revisiting: https://docs.docker.com/build/cache/

[mkesper]

That will rebuild the cache from upstream but not reproducibly.

[craftkiller]

Ah you're right, the hash wouldn't be the same but a Dockerfile could produce different outputs on different machines whereas nix will produce identical output on different machines.

[cpuguy83]

Producing different outputs isn't dockerfile's fault. Dockerfile doesn't enforce reproducibility but reproducibility can be achieved with it.

Nix isn't some magical thing that makes things reproducible either. nix is simply pinning build inputs and relying on caches. nixpkgs is entirely git based so you end up pinning the entire package tree.

[verdverm]

If you are building a binary on different arches, it will not be the same. I have many container builds that I can run while disabling the cache and get the same hash/bytes in the end, i.e. reproducible across machines, which also requires whatever you build inside be byte reproducible (like Go)