Open cdhanna opened 1 month ago
My main concern is the human angle: what is going to be most understandable and practically useful to the widest range of people using this system? Personally, I find that things being in a tarball feels like it is hiding information from me that would be more readily and familiarly available if it were simply a folder in the filesystem. Not sure whether that feeling is broadly held by other Game Makers, but I can say that the way I (and presumably thousands of other developers) was introduced to Docker's build mechanisms was by invoking docker build
in a command shell whose current directory was a folder containing a Dockerfile.
Being able to point at a specific directory and say, "that is exactly what went into building this Docker image," is immensely useful as a debugging tool.
After much thought, we don't need to be creating a tarball by hand anymore since we are using docker builtkit via the CLI now. We should remove our custom tar-balling and just rely on buildkits.
If we ever need to bring this back, its sitting in git! SHA 20a73ff2da6f0a3a20c4bbd3e0a56f19b414bfcb
--- (old) Today, the CLI
beam services deploy
command works by creating a tarball by hand, and passing it to the Docker API. However, in in CLI 2.1, the CLI will use buildkit via the CLI, and the tarball is being piped in via STDIN.Buildkit via the docker CLI could create its own tarball files, so technically we don't need to be creating it in advance. In fact, I bet that buildkit creates the tarball more efficiently than we do (just a wild guess).
The tarball file we have could be useful in remote builds, someday, but since today is not that day; should we delete the tarball allocation?