author new artifact types for OCI operations

[developer-guy]

We (w/@Dentrax) thought that one of the main goals of the OCI Artifacts¹ is that it allows you to author new artifact types that you want to support within your client tooling.² The first step of writing a new artifact type is to define a unique type for it.³ Defining a unique artifact allows various tools to know how to work with the type uniquely. When writing this, Flux's pull and push operations rely on the first layer of an image.⁴ As we can use client tools for registry and image operations such as crane, skopeo, etc., we have to know that we should put things to the first layer of an image, so, in today's world, we can store different things within the image layers in addition to the tarball. So, if we define Flux's artifact types for OCI, we can search them within image layers. With that, we don't need to limit ourselves to only storing things at the first layer of an image.

For example, OPA Rego policies can be stored on the OCI registry with their own types⁵; also, we have planned to do the same in Kyverno CLI⁶.

Footnotes

1. https://github.com/opencontainers/artifacts ↩

2. https://github.com/opencontainers/artifacts/blob/main/artifact-authors.md ↩

3. https://github.com/opencontainers/artifacts/blob/main/artifact-authors.md#defining-a-unique-artifact-type ↩

4. https://github.com/fluxcd/pkg/blob/8d88cfe7078e71936258a70e111bd6a429fa2bc8/oci/client/pull.go#L65 ↩

5. https://github.com/open-policy-agent/conftest/blob/master/internal/commands/push.go ↩

6. https://github.com/developer-guy/oci-kyverno/blob/master/main.go ↩

[stefanprodan]

This is covered by:

• [RFC-0003] Select layer by OCI media type flux2#3014
• [RFC-0003] Select layer by OCI media type source-controller#871

[developer-guy]

As Stefan mentioned, this was discussed in the given issues above, and I'm closing this one.