Along similar lines, when I was reading the article I was thinking "this just sounds like a slightly worse version of nix". Nix has the whole content addressed build DAG with caching, the intermediate language, and the ability to produce arbitrary outputs, but it is functional (100% of the inputs must be accounted for in the hashes/lockfile, as opposed to Docker where you can run commands like `apk add firefox` which is pulling data from outside sources that can change from day to day, so two docker builds can end up with the same hash but different output, making it _not_ reproducible like the article falsely claims).

Edit: The claim about the hash being the same is incorrect, but an identical Dockerfile can produce different outputs on different machines/days whereas nix will always produce the same output for a given input.

▲

ricardobeat 4 hours ago | parent | next [-]

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

	▲	craftkiller 2 hours ago \| parent \| next [-]
		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.
	▲	xyzzy_plugh 3 hours ago \| parent \| prev [-]
		It's not reproducible then, it's simply cached. It's a valid approach but there's tradeoffs of course.

▲

jasonpeacock 4 hours ago | parent | prev [-]

You can network-jail your builds to prevent pulling from external repos and force the build environment to define/capture its inputs.