add optional oci volumes field to resulting image config

[joshrwolf]

this is to support images that leverage a container runtime that uses the OCI spec volumes field (ref) to set up runtime volume mounts. it is a noop for all other runtimes

this supports the relatively small subset of cases where an image is built to run with docker, and needs certain mount configs to function. more concretely, the k3s container running in docker (ie: k3d). this runs containerd in docker by default with the overlayfs snapshotter, and requires a non overlayfs mount point to work. this is achieved upstream with a host volume mount (ref).

this change lets us mimic this behavior with something like:

...
volumes:
  - /var/lib/rancher/k3s

this only affects runtimes that actually parse the Volumes field (like docker).

related: wolfi-dev/os#2970 chainguard-images/images#877

[imjasonh]

Can you add something to https://github.com/chainguard-dev/apko/blob/main/docs/apko_file.md ?

[joshrwolf]

Can you add something to https://github.com/chainguard-dev/apko/blob/main/docs/apko_file.md ?

this sounds like a cop out, but I almost prefer not to, the use case here is so few and far between I'm worried it'll confuse end users between path/volume.

I inline commented the struct, so in the future when we have a json schema for autocomplete it'll show up, is that good enough?

[imjasonh]

Can you add something to https://github.com/chainguard-dev/apko/blob/main/docs/apko_file.md ?

this sounds like a cop out, but I almost prefer not to, the use case here is so few and far between I'm worried it'll confuse end users between path/volume.

I inline commented the struct, so in the future when we have a json schema for autocomplete it'll show up, is that good enough?

Yeah, that sounds fine. We might want to add something later and just surround it by big scary "you probably do not want this" warnings.