- A local Docker build might have issues due to your local computer's environment that cause mysterious or hard-to-replicate problems.
- You might not have permission to push new images to your organization's Docker repo from your computer.
- You might be on slow internet, or your docker images large enough, such that pushing on the cloud is 10-100x faster than pushing locally. (this is my pain point)
- You need to remember, and use, whatever Docker image tagging scheme your organization requires.
This always comes and bites us back isn't it? The whole promise of Docker was that we would be freed form these pains... But yet here we stand :(
Wondering what kind of issues you're running into. The first one that comes to mind for me is Kernel version mismatches. Though those shouldn't always cause that much trouble due to the "Dont break userspace mantra" that Linus has
Exactly. Using a separate build host makes builds more independent but on the other hand you'll be running images that the dev did not check.
By the way, are docker image identifiers derived from the actual contents? (Are they reproducible?)
This would suggest they are not:
> Docker images are non-reproducible: each "layer" identifier is a random hex string (and not cryptographic hash of the layer content),
Source: https://blog.bazel.build/2015/07/28/docker_build.html
However, it's still very difficult to generate the same layer ID twice. Timestamps permeate the layer contents itself in the form of file mtimes. The final image metadata itself also contains several timestamps.
Docker has a local cache of layers that helps simulate reproducibility. But if you clear that cache or use a different build machine, you will have a very hard time ever generating the same layer ID again.