[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

[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)