upvote

points

by moochmooch8 hours ago |
comments
upvoteby kccqzy8 hours ago|
next
[-]
Make is timestamp based. That is a thoroughly out-of-date approach only suitable for a single computer. You want distributed hash-based caching in the modern world.
reply
upvoteby moochmooch2 hours ago|
parent|
[-]
so use Bazel or buck2 if you need an iteration on make's handling of changed files. Bazel is much more serious of a project than buildkit. I'm not saying make is more functional that buildkit (it might be to some), I'm saying its better written software than buildkit. two separate things
reply
upvoteby kccqzy9 minutes ago|
parent|
next
[-]
Oh I love Bazel. The problem is that it’s harder to adopt for teams used to just using make. For a particular project at work, I argued unsuccessfully for switching from plain make to bazel, and it ended up switching to cmake.
reply
upvoteby literalAardvark1 hours ago|
parent|
prev|
[-]
Bazel just seems so... Academic. I can't make heads or tails of it.

Compared to a Dockerfile it's just too hard to follow

reply
upvoteby craftkiller8 hours ago|
prev|
next
[-]
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.

reply
upvoteby Izkata2 hours ago|
parent|
next
[-]
> whereas nix will always produce the same output for a given input.

If they didn't take shortcuts. I don't know if it's been fixed, but at one point Vuze in nix pulled in an arbitrary jar file from a URL. I had to dig through it because the jar had been updated at some point but not the nix config and it was failing at an odd place.

reply
upvoteby ricardobeat7 hours ago|
parent|
prev|
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.

reply
upvoteby xyzzy_plugh7 hours ago|
parent|
next
[-]
It's not reproducible then, it's simply cached. It's a valid approach but there's tradeoffs of course.
reply
upvoteby craftkiller6 hours ago|
parent|
prev|
[-]
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.
reply
upvoteby jasonpeacock8 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.
reply
upvoteby stackskipton6 hours ago|
prev|
[-]
SRE here, I feel like both are just instructions how to get source code -> executable with docker/containers providing "deployable package" even if language does not compile into self-contained binary (Python, Ruby, JS, Java, .Net)

Also, there is nothing stopping you from creating a container that has make + tools required to compile your source code, writing a dockerfile that uses those tools to produce the output and leave it on the file system. Why that approach? Less friction for compiling since I find most make users have more pet build servers then cattle or making modifications can have a lot of friction due to conflicts.

reply