Don't forget bump the date. :-)

I'd suggest committing this part immediately, separate from this overall change

Typo - ICO / OCI

Move this down to line 166 and make it DISTRIBUTIONS+= container-image-${_IMG}.txz.

How much do these packages do? We use bits from the ports tree to build and upload cloudware but I'd prefer to avoid external dependencies as much as possible in the base system build.

Can this be split into three scripts, or possibly one script with three configuration files? I prefer "one tool builds one thing" (and that might make the Makefile logic cleaner too).

I think this can be included in RELEASE_RMAKEFLAGS?

The buildah tool is used to build the container images and keeps track of image metadata as well as calculating differences between an image and the one it is derived from. The skopeo tool is used to copy these images to oci-archive format tarballs. Neither tool is used at all in the build process itself, only in creating the container images from pkgbase packages.

In theory, it would be possible to create the oci-archive tarballs manually but it would be a lot of work for very little gain (IMO).

Extremely minor nit but I would put WITH_OCIIMAGES after WITH_CLOUDWARE, leaving XZ_THREADS last, seems logical to keep the WITH_ variables together

I wonder if these mtree files should be based on ${curdir} instead of the host root?
The same is true for all the files copied from the host, shouldn't they be copied from the git tree (i.e., ${curdir})?

This is a good question. In the past, I installed FreeBSD-mtree into a temp directory and built the container directory tree from that. For this iteration, since release.sh will typically do a buildworld+installworld first it seemed reasonable to use mtree and other files from the chroot.

I do not understand the naming convention?
I would imagine:

freebsd:latest <-> freebsd:<short-commit-id> <-> freebsd:15 (different tags, same image)
freebsd-minimal:latest
freebsd-slim:latest
freebsd:14.2-RELEASE <-> freebsd:14.2

That is, having the version number after the colon.

Sorry, please ignore this suggestion, as it will leave ASSUME_ALWAYS_YES=yes in the environment of the final image. This may not always be desired.

Now that I think about it, I don't think we really want these to end up in e.g. https://download.freebsd.org/releases/amd64/14.2-RELEASE/. They should land in https://download.freebsd.org/releases/OCI-IMAGES/14.2-RELEASE/amd64/Latest/ like we do for CI-IMAGES and VM-IMAGES. So putting them into the list of "distributions" doesn't seem quite right.

Thinking about this a bit more... these aren't really "distributions" in the sense of things users select to include or exclude from the installer. So I'm not sure we need them in this file at all.

I would prefer to see these as one release/scripts/make-oci.sh file and three release/tools/oci-*.conf files, just for consistency with how we do the VM builds. Would that be possible?

This is mainly to allow e.g. both freebsd14-minimal:latest and freebsd15-minimal:latest to exist without conflict.

That makes sense - I'll take a look at how this is done for VM images and try to match that.

Precisely, isn't the "convention" something like:

freebsd-minimal:15, freebsd-minimal:<short-commit-id>, freebsd-minimal:{edge,rolling}
freebsd-minimal:14, freebsd-minimal:latest
freebsd-minimal:13

It looks like you want to ship a "latest" version for every FreeBSD version?

But, this can be revisited post-commit. The main objective is to start producing these images.

But, this can be revisited post-commit. The main objective is to start producing these images.

The naming is hard, but I'd like to have it more precise. What about

freebsd:14.1-p2 freebsd:14.2 freebsd:14
freebsd-minimal:14.1-p2 freebsd-minimal:14.2 freebsd-minimal:14
freebsd:13.4-p5 freebsd:13.4 freebsd:13

for RELEASE versions, and

freebsd-stable:14-<short-commit-id> freebsd-stable:14
freebsd-stable-minimal:14-<short-commit-id> freebsd-stable-minimal:14
freebsd-stable:13-<short-commit-id> freebsd-stable:13

for STABLE versions, and

freebsd-current:<short-commit-id> freebsd-current:latest
freebsd-current-minimal:<short-commit-id> freebsd-current-minimal:latest

for CURRENT dev versions ?

We typically support two major versions, sometimes three, so having a latest tag for each seems useful.

Longer term, we could mark the images with suitable OS version but since this feature is only currently used for Windows, it would require changes to the various container engines - in particular Podman and CRI-O currently ignore this field.