earthly/earthly
image requires that it is run as --privileged
, if it is meant to be used with the embedded BuiltKit daemon. This is mainly due to the use of overlayfs and the internal networking setup.earthly/earthly
image is used with a pinned version when used in the context of a CI, in order to avoid accidental future breakage as earthly
evolves./usr/bin/earthly-entrypoint.sh
as the entrypointearthly/earthly
image comes with an entrypoint that first starts up BuildKit and then issues an earthly
command that makes use of it. You may use the image just as you would use earthly
itself otherwise. Any arguments are passed into the earthly
command directly.earthly
binary as the entrypoint will not start up BuildKit within the same container and will instead attempt to use the Docker Daemon (assuming one is available via /var/run/docker.sock
) to start up BuildKit.earthly/earthly
image in conjunction with a remote BuildKit Daemon. You may use the environment variable BUILDKIT_HOST
to specify the hostname of the remote BuildKit Daemon. When this environment variable is set, the earthly/earthly
image will not attempt to start BuildKit and will instead use the remote BuildKit Daemon./workspace
). You will need to copy or mount the necessary files to that directory prior to invoking the entrypoint.NO_DOCKER
Environment Variable--ci
flag disables output by default. In such circumstances, you can use the NO_DOCKER
environment variable to disable checking for the presence of Docker. This will disable some warnings that would otherwise be printed to the console as Earthly starts up.EARTHLY_TMP_DIR
. If you do not, Buildkit can consume excessive disk space, operate very slowly, or it might not function correctly.EARTHLY_TMP_DIR
as a Docker volume results in the following error:emptyDir
worked.EARTHLY_TMP_DIR
and whether WITH DOCKER
worked well for you.