You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The platform level to force for the build. Normally the platform level is determined from the intersection of the builder image supported levels, and the platform implementation supported levels. Sometimes it can be beneficial to force the platform to a particular version to force behavior during the build.
Should the builder image be 'trusted' (use creator lifecycle)
2611
+
Should the builder image be 'trusted' ? Trusted builders are allowed to attempt to use the `creator` lifecycle, which runs all the build phases within a single container. This is only possible for builders that do not use extensions. Running all phases in one container exposes some phases to information they may not see normally with a container-per-phase.
The buildpacks run image to use when building the project When not supplied, the run image is determined by the builder image.
2716
+
The buildpacks run image to use when building the project When not supplied, the run image is determined by the builder image. If extensions are used by the builder image, they may override the run image.
DOCKER_HOST value to use. If not set, the env var DOCKER_HOST is used, if that is not set the platform will look for 'npipe:///./pipe/docker_engine' for windows, and `unix:///var/run/docker.sock' then `unix:///var/run/podman.sock` then `unix:///var/run/user//podman/podman.sock` for linux
2800
+
DOCKER_HOST value to use. This value is normally auto-determined, and is available for override if needed. If not set, the env var DOCKER_HOST is used, if that is not set the platform will test if `podman` is available on the path, if so, it will use podman to configure the appropriate values. If `podman` is not on the path, docker is assumed, and per-platform defaults for docker are used.
Path to the Docker socket to use. This value is normally auto-determined, and is available for override if needed. The path to the socket can vary, especially when the docker/podman daemon is running inside a VM, if useDaemon mode is true, then this path must refer to the path that can be used to mount the socket inside a container, so may refer to the path to the socket in the VM rather than the host.
use Daemon mode? Should the buildpack build have the docker socket mounted into the build container(s). If this is false, then the image will be built directly as layers in a remote registry, this will probably require registry credentials to be passed. Defaults to 'true'
Use specified docker network during build This can be handy when building against a locally hosted docker registry, where you will require the build containers to be part of the 'host' network to enable them to access the local registry.
Log level to use. The log level to use when executing the build phases in containers. Defaults to 'info', supported values are 'info', 'warn' and 'debug'
a|tooltip:netty[Uses a Netty-based transport re-using the existing Netty event loops.], tooltip:mongo[With a reactive driver it uses an async transport backed by a driver-managed thread pool, while with a blocking driver it uses a blocking transport.]
65187
+
a|tooltip:netty[Uses a Netty-based transport re-using the existing Netty event loops.], tooltip:mongo[With a reactive driver it uses an async transport backed by a driver-managed thread pool.]
65083
65188
|tooltip:netty[Uses a Netty-based transport re-using the existing Netty event loops.]
a|tooltip:netty[Uses a Netty-based transport re-using the existing Netty event loops.], tooltip:mongo[With a reactive driver it uses an async transport backed by a driver-managed thread pool, while with a blocking driver it uses a blocking transport.]
65104
-
|tooltip:mongo[With a reactive driver it uses an async transport backed by a driver-managed thread pool, while with a blocking driver it uses a blocking transport.]
a|tooltip:netty[Uses a Netty-based transport re-using the existing Netty event loops.], tooltip:mongo[With a reactive driver it uses an async transport backed by a driver-managed thread pool, while with a blocking driver it uses a blocking transport.]
65784
+
a|tooltip:netty[Uses a Netty-based transport re-using the existing Netty event loops.], tooltip:mongo[With a reactive driver it uses an async transport backed by a driver-managed thread pool.]
65701
65785
|tooltip:netty[Uses a Netty-based transport re-using the existing Netty event loops.]
a|tooltip:netty[Uses a Netty-based transport re-using the existing Netty event loops.], tooltip:mongo[With a reactive driver it uses an async transport backed by a driver-managed thread pool, while with a blocking driver it uses a blocking transport.]
65722
-
|tooltip:mongo[With a reactive driver it uses an async transport backed by a driver-managed thread pool, while with a blocking driver it uses a blocking transport.]
0 commit comments