> You can absolutely build images with a bash script, here's an example
That script is just calling docker to build layers manually via `docker create`/`docker commit`/`docker run`/etc, using a Dockerfile as a rudimentary DSL over it. It's still building images "the way docker does", but in a more error-prone way.
What GP is trying to say with "I would've been happy with a Bash script, or handing it a tarball", is that it ought to support giving it a literal tarball, like you'd get via `make install DESTDIR=./out && tar -czf image.tgz -C ./out .`. Or just tar'ing up the build artifacts of any other existing, competent build systems. There's no need to treat building an image as some "containerized" thing where you have to run inside the bottom layer of the container to build the artifacts.
In fact nowadays with the best practice of split container builds, there's no benefit of saying "the container is guaranteed to have the dependencies because it's the container you built with", because in practice nobody wants to ship their runtime containers with an entire build environment in them. So they do one container to do the building, then pick out the artifacts they need and place them in the runtime container. At that point, what's the point of using containers to build again?
That script is just calling docker to build layers manually via `docker create`/`docker commit`/`docker run`/etc, using a Dockerfile as a rudimentary DSL over it. It's still building images "the way docker does", but in a more error-prone way.
What GP is trying to say with "I would've been happy with a Bash script, or handing it a tarball", is that it ought to support giving it a literal tarball, like you'd get via `make install DESTDIR=./out && tar -czf image.tgz -C ./out .`. Or just tar'ing up the build artifacts of any other existing, competent build systems. There's no need to treat building an image as some "containerized" thing where you have to run inside the bottom layer of the container to build the artifacts.
In fact nowadays with the best practice of split container builds, there's no benefit of saying "the container is guaranteed to have the dependencies because it's the container you built with", because in practice nobody wants to ship their runtime containers with an entire build environment in them. So they do one container to do the building, then pick out the artifacts they need and place them in the runtime container. At that point, what's the point of using containers to build again?