beamable / BeamableProduct

The beamable product suite including com.beamable, com.beamable.server, microservice base image, portal, the installer, and build scripts
Other
5 stars 0 forks source link

CLI - remove the image tar-balling #3556

Open cdhanna opened 1 month ago

cdhanna commented 1 month ago

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?

allister-beamable commented 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.