Package io.quarkus.container.image.jib.deployment

Class JibConfig

  • @ConfigRoot(phase=BUILD_TIME)
public class JibConfig
extends Object

    • Field Detail

      • baseJvmImage

        @ConfigItem
public Optional<String> baseJvmImage
        The base image to be used when a container image is being produced for the jar build. When the application is built against Java 17 or higher, registry.access.redhat.com/ubi8/openjdk-17-runtime:1.15 is used as the default. Otherwise registry.access.redhat.com/ubi8/openjdk-11-runtime:1.15 is used as the default.

      • baseNativeImage

        @ConfigItem(defaultValue="quay.io/quarkus/quarkus-micro-image:2.0")
public String baseNativeImage
        The base image to be used when a container image is being produced for the native binary build. The default is "quay.io/quarkus/quarkus-micro-image". You can also use "registry.access.redhat.com/ubi8/ubi-minimal" which is a bigger base image, but provide more built-in utilities such as the microdnf package manager.

      • jvmArguments

        @ConfigItem(defaultValue="-Djava.util.logging.manager=org.jboss.logmanager.LogManager")
public List<String> jvmArguments
        The JVM arguments to pass to the JVM when starting the application

      • jvmAdditionalArguments

        @ConfigItem
public Optional<List<String>> jvmAdditionalArguments
        Additional JVM arguments to pass to the JVM when starting the application

      • nativeArguments

        @ConfigItem
public Optional<List<String>> nativeArguments
        Additional arguments to pass when starting the native application

      • jvmEntrypoint

        @ConfigItem
public Optional<List<String>> jvmEntrypoint
        If this is set, then it will be used as the entry point of the container image. There are a few things to be aware of when creating an entry point
        • Entrypoint "INHERIT" means to inherit entrypoint from base image, jvmArguments field is used for arguments
        • A valid entrypoint is jar package specific (see quarkus.package.type)
        • A valid entrypoint depends on the location of both the launching scripts and the application jar file. To that end it's helpful to remember that when fast-jar packaging is used (the default), all necessary application jars are added to the /work directory and that the same directory is also used as the working directory. When legacy-jar or uber-jar are used, the application jars are unpacked under the /app directory and that directory is used as the working directory.
        • Even if the jvmArguments field is set, it is ignored completely unless entrypoint is "INHERIT"
        When this is not set, a proper default entrypoint will be constructed. As a final note, a very useful tool for inspecting container image layers that can greatly aid when debugging problems with endpoints is dive

      • nativeEntrypoint

        @ConfigItem
public Optional<List<String>> nativeEntrypoint
        If this is set, then it will be used as the entry point of the container image. There are a few things to be aware of when creating an entry point
        • Entrypoint "INHERIT" means to inherit entrypoint from base image, nativeArguments field is used for arguments
        • A valid entrypoint depends on the location of both the launching scripts and the native binary file. To that end it's helpful to remember that the native application is added to the /work directory and that and the same directory is also used as the working directory
        • Even if the nativeArguments field is set, it is ignored completely unless entrypoint is "INHERIT"
        When this is not set, a proper default entrypoint will be constructed. As a final note, a very useful tool for inspecting container image layers that can greatly aid when debugging problems with endpoints is dive

      • environmentVariables

        @ConfigItem
public Map<String,​String> environmentVariables
        Environment variables to add to the container image

      • labels

        @ConfigItem
@Deprecated
public Map<String,​String> labels
        Deprecated.
        Use 'quarkus.container-image.labels' instead
        Custom labels to add to the generated image

      • baseRegistryUsername

        @ConfigItem
public Optional<String> baseRegistryUsername
        The username to use to authenticate with the registry used to pull the base JVM image

      • baseRegistryPassword

        @ConfigItem
public Optional<String> baseRegistryPassword
        The password to use to authenticate with the registry used to pull the base JVM image

      • ports

        @ConfigItem(defaultValue="${quarkus.http.port:8080}")
public List<Integer> ports
        The ports to expose

      • user

        @ConfigItem
public Optional<String> user
        The user to use in generated image

      • workingDirectory

        @ConfigItem(defaultValue="/home/jboss")
public String workingDirectory
        The working directory to use in the generated image. The default value is chosen to work in accordance with the default base image.

      • alwaysCacheBaseImage

        @ConfigItem(defaultValue="false")
public boolean alwaysCacheBaseImage
        Controls the optimization which skips downloading base image layers that exist in a target registry. If the user does not set this property, then read as false. If true, base image layers are always pulled and cached. If false, base image layers will not be pulled/cached if they already exist on the target registry.

      • platforms

        @ConfigItem
public Optional<Set<String>> platforms
        List of target platforms. Each platform is defined using the pattern: 
          <os>|<arch>[/variant]|<os>/<arch>[/variant]
        for example: 
         linux/amd64,linux/arm64/v8
        If not specified, OS default is linux and architecture default is amd64. If more than one platform is configured, it is important to note that the base image has to be a Docker manifest or an OCI image index containing a version of each chosen platform. The feature does not work with native images, as cross-compilation is not supported. This configuration is based on an incubating feature of Jib. See Jib FAQ for more information.

      • imageDigestFile

        @ConfigItem(defaultValue="jib-image.digest")
public String imageDigestFile
        The path of a file in which the digest of the generated image will be written. If the path is relative, the base path is the output directory of the build tool.

      • imageIdFile

        @ConfigItem(defaultValue="jib-image.id")
public String imageIdFile
        The path of a file in which the id of the generated image will be written. If the path is relative, the base path is the output directory of the build tool.

      • offlineMode

        @ConfigItem(defaultValue="false")
public boolean offlineMode
        Whether or not to operate offline.

      • dockerExecutableName

        @ConfigItem
public Optional<String> dockerExecutableName
        Name of binary used to execute the docker commands. This is only used by Jib when the container image is being built locally.

      • dockerEnvironment

        @ConfigItem
public Map<String,​String> dockerEnvironment
        Sets environment variables used by the Docker executable. This is only used by Jib when the container image is being built locally.

      • useCurrentTimestamp

        @ConfigItem(defaultValue="true")
public boolean useCurrentTimestamp
        Whether to set the creation time to the actual build time. Otherwise, the creation time will be set to the Unix epoch (00:00:00, January 1st, 1970 in UTC). See Jib FAQ for more information

      • useCurrentTimestampFileModification

        @ConfigItem(defaultValue="true")
public boolean useCurrentTimestampFileModification
        Whether to set the modification time (last modified time) of the files put by Jib in the image to the actual build time. Otherwise, the modification time will be set to the Unix epoch (00:00:00, January 1st, 1970 in UTC). If the modification time is constant (flag is set to false so Unix epoch is used) across two consecutive builds, the docker layer sha256 digest will be different only if the actual files added by Jib to the docker layer were changed. More exactly, having 2 consecutive builds will generate different docker layers only if the actual content of the files within the docker layer was changed. If the current timestamp is used the sha256 digest of the docker layer will always be different even if the content of the files didn't change.

    • Constructor Detail

      • JibConfig

        public JibConfig()