The `buildContainerImage2` function is an improvement on the existing
`buildContainerImage` function, with a couple of enhancements.
Primarily, it supports building images for multiple architectures. For
each listed architecture, a pod is launched on a matching worker node to
build the image natively. The image is exported to an OCI archive and
"stashed" in the Jenkins workspace. After images for all architectures
are built, another pod is launched and all of the stashed archives are
copied there and assembled into a manifest list. Finally, the manifest
list is published to the OCI repository as usual, creating tags for the
Git branch and build number.
In addition to adding support for multiarch images, the
`buildContainerImage2` performs image builds in *unprivileged* pods.
Whereas the old function performed builds in a rootful container, the
new one configures requests pods with unique user namespaces. The build
runs as *root* in the container, but that user is mapped to an arbitrary
unprivileged user on the host.
If the `buildContainerImage` method is called without passing any
arguments at all, the `args` object will be `null`. Attempting to
access the properties of it in that case raises a
`NullPointerException`. Fortunately, Groovy has a `?` operator that
returns `null` when the named object is `null` and avoids accessing its
properties.
The `buildContainerImage` method now supports an optional `arch` keyword
argument. This argument can be used to select the architecture of the
node running the pod building the container image. If unspecified, it
defaults to `amd64`.
The `registry`, `project`, `name`, and `tag` values can now be passed as
keyword arguments to the `buildContainerImage` function. This will
allow jobs to override the default values if necessary.
Dustin