* You can mount build-time secrets in safely with `--mount-type=secret`, instead of passing them in. (Multistage builds do alleviate the problems with passing secrets in, but not completely.)
* Mount apt-cache dirs in at build time with `--mount-type bind` so that you don't have to apt-get update every single time, and you don't have to clear apt-caches either.
And lots more.
Notice that this mostly involves capabilities that Docker already has to build time.
I assume you mean the helper for COPY/ADD is pulled from the registry. That is not the case since Buildkit v0.5 / Docker v19.03 . If you have images you use locally, network connectivity is not required, otherwise, BuildKit will verify that the mutable tags have not changed in the registry (eg. it doesn't use the string "latest" to verify the validity of cache).
The message without internet connection is: ERROR resolve image config for docker.io/docker/dockerfile:1.0-experimental (the most current version of Docker Desktop for Windows - 2.0.0.3 with Docker Engine 18.09.2)
As I mentioned you need to have the images you use available locally (eg. `docker images | grep docker/dockerfile`). In your Dockerfile you explicitly say that you want to use docker/dockerfile:1.0-experimental from the hub as a build frontend. If there is no such name/tag locally it needs to check the state in the registry as `1.0-experimental` tag is updated on new releases.
BuildKit is an experimental replacement for docker build from Docker Ltd. When building it fetches some metafiles from the internet. So you can not use it in isolated environments...
Yeah but why would you build in that kind of tech debt in the first place? It seems a lot of effort to host meta files and keep that available than some other solution that doesn't require internet access.
If I were to propose to my team that we install a temporary measure in the form of an additional service that needs availability they would smack me down, because that's a pretty stupid temporary measure.
Software is generally published online. Docker image repositories are generally online. The very act of building a Docker image pulling in dependencies is generally done online.
It was a deep hack into the entirety of the Docker build chain. This way it was probably possible to publish experimental work-in-progress build features to the world at a faster pace than the official Docker release cycle.
And as pointed out above, the online-only requirement has been lifted already.
The situation is perfectly understandable, and to be commended that people offered to do this work for the betterment of all.
* You can mount build-time secrets in safely with `--mount-type=secret`, instead of passing them in. (Multistage builds do alleviate the problems with passing secrets in, but not completely.)
* Buildkit automatically parallelizes build stages. (Of course!)
* Mount apt-cache dirs in at build time with `--mount-type bind` so that you don't have to apt-get update every single time, and you don't have to clear apt-caches either.
And lots more.
Notice that this mostly involves capabilities that Docker already has to build time.