9 ms·
> “don’t do this” Yes. The Bazel way use to produce binaries, files, directories, and then create an image “directly” from these. Much as you would create a J
by paulddraper 10mo ago
> “don’t do this”
Yes. The Bazel way use to produce binaries, files, directories, and then create an image “directly” from these.
Much as you would create a JAR or ZIP or DEB.
This is (1) fast (2) small and (3) more importantly reproducible. Bazel users want their builds to produce artifacts that are exactly the same, for a number of reasons. Size is also nice…do you really need ls and dozens of other executables in your containerized service?
Most Docker users don’t care about reproducibility. They’ll apt-get install and get one version today and another version tomorrow.
Good? Bad? That’s a value judgement. But Bazel users have fundamentally different objectives.
> emulators
Yeah emulators is the Docker solution for producing images of different architectures.
Since Bazel doesn’t run commands as a running container, it skips that consideration entirely.
- cyberax 10mo ago> Size is also nice…do you really need ls and dozens of other executables in your containerized service? Yeah, I do. For debugging mostly :( > Most Docker users don’t care about reproducibility. They’ll apt-get install and get one version today and another version tomorrow. Ubuntu has daily snapshots. Not great, but works reasonably well. I tried going down the Nix route, but my team (well, and also myself) struggled with it. I'd love to have fully bit-for-bit reproducible builds, but it's too complicated with the current tooling. Especially for something like mobile iOS apps (blergh).