Open joonas-fi opened 4 months ago
OCI layout seems pretty ideal for storing on-disk and then pushing that.
Sample Dockerfile
:
FROM alpine:latest
RUN apk add --no-cache curl
And a build command:
docker-buildx build --output=type=oci,dest=oci.tar --attest=type=sbom .
mkdir oci && cd oci && tar -xf ../oci.tar
Now we have the build result in OCI on-disk directory format.
One can then push it to temporary registry:
IMAGE_NAME=6012b4ab-8f47-46cc-83de-a0db6cf11c48
oras cp --from-oci-layout ./oci/@sha256:445a1965b26e2527f4071ce2673f003bf63a3c1cfed085589811c50b1d03bca2 ttl.sh/${IMAGE_NAME}:1h
NOTE: sha256:445a196...
was resolved from oci/index.json
. It points to the manifest list.
Why at lower level?
The legacy
$ docker build ...
command doesn't produce a manifest list (= "multi-arch image")The new
$ docker buildx build ...
command produces a manifest list but is rigid in how it works.. there's not a lot of headroom to inject custom stuff in there such as ORAS artifacts. The result of that build is already pushed (= published) to the registry.Ideally we'd assemble a manifest list ourselves and push that to the registry.
We'd be able to build the manifest list out of pieces:
$ docker buildx build ...