Build

This goal will build all images which have a <build> configuration section. There must be a Containerfile present in order to build a container image.

Building a container image without a Containerfile, thus purely on configuration is currently not supported.

Build Configuration

This section covers all the possible options for the <build> tag.

Table 1. Build configuration options
Element	Description
skipBuild	If set to true the plugin won’t build any images.
skipCatalog	If set to true the plugin won’t create the `container-catalog.txt` file.
skipTag	If set to true the plugin won’t tag any images. Default value is: `false`
layers	Cache intermediate images during the build process (Default is `true`). Note: You can also override the default value of layers by setting the BUILDAH_LAYERS environment variable. `export BUILDAH_LAYERS=true` Default value is: `null` (not specified). See: https://docs.podman.io/en/latest/markdown/podman-build.1.html
platform	Specifies the platform to be passed to Podman to control the operating system, architecture and variants of the resulting image. Default value is: `null` (not specified and Podman will build a container that targets the system doing the container build) Example value for linux x86_64 is: linux/amd64 Example value for linux aarch64 is: linux/arm64 See (--platform): https://docs.podman.io/en/latest/markdown/podman-build.1.html
noCache	Do not use existing cached images for the container build. Build from the start with a new set of cached layers. Default value is: `false`
pull	When the option is specified or set, pull the image. Raise an error if the image could not be pulled, even if the image is present locally. If the option is disabled (with `<pull>never</pull>`) or not specified, pull the image from the registry only if the image is not present locally. Raise an error if the image is not found in the registries and is not present locally. Default value is: `null` (not specified). Supported values are: ALWAYS, TRUE, MISSING, NEVER, FALSE, NEWER See: https://docs.podman.io/en/latest/markdown/podman-build.1.html#pull-policy
squash	Squash all of the image’s new layers into a single new layer; any preexisting layers are not squashed. Default value is: `null` (not specified). See: https://docs.podman.io/en/latest/markdown/podman-build.1.html
squashAll	Squash all of the new image’s layers (including those inherited from a base image) into a single new layer. Default value is: `null` (not specified). See: https://docs.podman.io/en/latest/markdown/podman-build.1.html
tags	An array consisting of one or more tags to attach to the built container image. Tags will be appended at the end of the image name.
targetStage	Set the target build stage to build. When building a Containerfile with multiple build stages, it can be used to specify an intermediate build stage by name as the final stage for the resulting image. Commands after the target stage is skipped. Default value is: `null` (not specified). See: https://docs.podman.io/en/latest/markdown/podman-build.1.html
containerFile	The name of the `Containerfile` to build. If you are using a `Dockerfile` you should change this parameter. Default value is: `Containerfile`
containerFileDir	Path of the directory where the `Containerfile` is located. Default value is: Project base directory
labels	A collection of labels to add to this image. They are specified in the typical maven property format.
args	Specifies one or more build arguments and their value, which will be interpolated in instructions read from the Containerfiles in the same way that environment variables are, but which will not be added to environment variable list in the resulting image’s configuration. Syntax: `<arg>value</arg>` See: https://docs.podman.io/en/latest/markdown/podman-build.1.html#build-arg-arg-value
tagWithMavenProjectVersion	When set to `true`, the resulting container image will be tagged with the current version of the Maven project. Default value is: `true`
createLatestTag	Specifies whether the resultig container image should be tagged with `latest`. Default value is: `false`
format	Control the format for the built image’s manifest and configuration data. Supported values are: DOCKER (version 2, using schema format 2 for the manifest) OCI (OCI image-spec v1.0, the default) Default value is: `OCI` See: https://docs.podman.io/en/latest/markdown/podman-build.1.html
ulimits	Specifies one or more user limits, such as `nofile` (number of open files), permitted in the build container. Necessary, because `podman build` does not pass the current user session’s user limits into the build container, breaking, e.g., large Java builds. Syntax: `<type>soft-limit[:hard-limit]</type>` Type is one of (core cpu data fsize locks memlock msgqueue nice nofile nproc rss rtprio rttime sigpending stack). See: https://docs.podman.io/en/latest/markdown/podman-build.1.html#ulimit-type-soft-limit-hard-limit

Listing 1. Example configuration

<configuration>
    ...
    <images>
        <image>
            <name>your-image-name</name>
            <build>
                <pull>always</pull>
                <tags>
                    <sampleTag>sampleTagValue</sampleTag>
                </tags>
                <createLatestTag>true</createLatestTag>
                <format>OCI</format>
                <args>
                    <buildArg1>buildArgValue1</buildArg1>
                    <buildArg2>buildArgValue2</buildArg2>
                </args>
            </build>
        </image>
    </images>
    ...
</configuration>

Batch Configuration

When using the <batch/> configuration option, some configuration options are interpreted slightly different, compared to the explanation in the table above. The table below lists all these configuration options that are interpreted differently.

Please be advised that you can only configure one run directory for podman (see General Configuration). This needs to be taken into account when designing your Containerfile s

Element Description

Element	Description
`containerFileDir`	The directory in which all `Containerfile` s should be found. `Containerfile` s are searched for recursively and do not need to be at this exact level.

containerFileDir

The directory in which all Containerfile s should be found. Containerfile s are searched for recursively and do not need to be at this exact level.

Labels

Labels are a mechanism for applying metadata to container images. Labels can be used to order images. A label is a key-value pair, stored as a string. You can specify multiple labels for an object, but each key-value pair must be unique within an object. If the same key is given multiple values, the most-recently-written value overwrites all previous values.

As of version 1.7.1 label values are always stored between double quotes to allow values with spaces.

Build arguments

Specifies one or more build arguments and their value, which will be interpolated in instructions read from the Containerfiles in the same way that environment variables are, but which will not be added to environment variable list in the resulting image’s configuration.

Build arguments can also be specified via System Properties, using the syntax: podman.buildArg.exampleBuildArgument=buildArgumentValue. Do note that System Properties are global and take precedence over the arguments that are configured in the build configuration for each image.

Key format recommendations

A label key is the left-hand side of the key-value pair. Keys are alphanumeric strings which may contain periods (.) and hyphens (-). Most Podman users use images created by other organizations, and the following guidelines help to prevent inadvertent duplication of labels across objects, especially if you plan to use labels as a mechanism for automation.

Value guidelines

Label values can contain any data type that can be represented as a string, including (but not limited to) JSON, XML, CSV, or YAML. The only requirement is that the value be serialized to a string first, using a mechanism specific to the type of structure. For instance, to serialize JSON into a string, you might use the JSON.stringify() JavaScript method.

Since Podman does not deserialize the value, you cannot treat a JSON or XML document as a nested structure when querying or filtering by label value unless you build this functionality into third-party tooling.