Multi gigabyte containers everywhere.
Containers nicely solve this problem. Then your builds get a little slow, so you want to cache things. Now your docker file looks like this. You want to run some tests - now it’s even more complicated. How do you debug those tests? How do those tests communicate with external systems (database/redis). Eventually you end up back at “let’s just containerise the packaging”.
Here's an example of that from the docker maven.
`docker run -it --rm --name my-maven-project -v "$(pwd)":/usr/src/mymaven -w /usr/src/mymaven maven:3.3-jdk-8 mvn clean install`
You can get as fancy as you like with things like your `.m2` directory, this just gives you the basics of how you'd do that.
(and of course, nix kinda blows both out the water for consistency)
A lot of teams should think long and hard about just taking build artifacts, throwing them into their expected places in a directory taking the place of chroot, generating a manifest JSON, and wrapping everything in a tar, which is indeed a container.
We have our base images, and in there we install dependencies by version. That package then is the base for our code build. (as apt seemingly doesn't have any lock file support?).
In the subsequent built EVERYTHING is versioned, which allows us to establish provenance all the way up to the base image.
And next to that when we promote images from PR -> main we don't even rebuild the code. It's the same image that gets retagged. All in the name of preserving provenance.
Doesn’t even need Docker, just writes the image files with a small Python script.
Can build from scratch, or use the very small Distroless images.
Also, I took a quick look and I don't understand how your tool could possibly produce "even smaller images". The article is using multi-stage builds to produce a final Docker image that is quite literally just the target binary in question (based on the scratch image), whereas your tool appears be a whole Linux distribution.
This would be a much smaller drop in replacement for the base images used in the post to give full source bootstrapped final binaries.
You can still from scratch for the final layer though of course and that would be unlikely to change size much though, to your point.
