4 ms·

> 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 b

> 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 8mo ago
It's not reproducible then, it's simply cached. It's a valid approach but there's tradeoffs of course.
- verdverm 8mo ago
  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 8mo ago
    The difference is that you can blow the Nix cache away and reproduce it entirely. The same cannot be said for Docker.
    - verdverm 8mo ago
      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/ https://docs.docker.com/build/cache/
      - mkesper 8mo ago
        That will rebuild the cache from upstream but not reproducibly.
craftkiller 8mo ago
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.
- verdverm 8mo ago
  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)
- cpuguy83 8mo ago
  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.

xyzzy_plugh 8mo ago

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

verdverm 8mo ago
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 8mo ago
  The difference is that you can blow the Nix cache away and reproduce it entirely. The same cannot be said for Docker.
  - verdverm 8mo ago
    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/ https://docs.docker.com/build/cache/
    - mkesper 8mo ago
      That will rebuild the cache from upstream but not reproducibly.

craftkiller 8mo ago

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.

verdverm 8mo ago
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)
cpuguy83 8mo ago
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.