Follow OCI container image annotation standards when generating containers

[NissesSenap]

As a part of generating a docker container when running something like: spin registry push ttl.sh/something:1h, we get very basic information about the container.

➜ docker manifest inspect ttl.sh/something:1h
{
    "config": {
        "digest": "sha256:668d372ccc29ffe6f0000bbddbff67d97c2812dbd48b5338ae8532ab6b7c4e59",
        "mediaType": "application/vnd.oci.image.config.v1+json",
        "size": 209
    },
    "layers": [
        {
            "digest": "sha256:2bcd094bfd433033c641264d94d0afbd0adabc666d69433d2f766e0efbe5e598",
            "mediaType": "application/vnd.wasm.content.layer.v1+wasm",
            "size": 36276905
        },
        {
            "digest": "sha256:3f05015b248403ca99a9bf1861202d107885ae300f5ff165708415603a39c248",
            "mediaType": "application/vnd.fermyon.spin.application.v1+config",
            "size": 596
        }
    ],
    "schemaVersion": 2
}

But there is an OCI standard for pre-defined annotations.

It would be great if spin could generate most of these annotations out of the box, if possible, guess them from context. But make it possible to set all values through thespin.toml file.

[vdice]

Thanks for creating this issue @NissesSenap. I'm sensing there might be a couple enhancements from this ticket.

Auto-populate relevant annotations

Of the pre-defined annotations, these seem to be natural choices for auto-generating, either from relevant image data or from pre-existing spin.toml metadata:

• org.opencontainers.image.created - time of spin registry push ?
• org.opencontainers.image.authors - application.authors from spin.toml
• org.opencontainers.image.version - application.version from spin.toml
• org.opencontainers.image.title - application.name from spin.toml
• org.opencontainers.image.description - application.description from spin.toml

Any others you're seeing?

Support annotation values via manifest?

Other annotations that can't currently be automatically derived today can be supplied at time of publishing, eg via spin registry push --annotation org.opencontainers.image.url=https://example.com.

However, as you've mentioned above, it may be handy to set annotation values in the manifest itself. This would require a bit more thought around design/ergonomics... my first instinct is maybe a new top-level section in the manifest eg [registry] and annotations could be defined under [registry.annotations] - perhaps this section would allow for any entry and any number of them as long as each entry is a key/value pair, eg annotation = value. Any annotation also provided at time of publishing via CLI (eg via --annotation annotation=value) would take precedence over the key/value set in the manifest. (In the future, I could envision other metadata under [registry] such as a default registry name, reference, etc.)

Is this along the lines of what you were thinking of?

[NissesSenap]

Hi @vdice , thank you for your quick reply. I agree with the pre-defined annotations that you listed. I also like the idea of creating a new section in the manifest called [registry].

As you point out, future things like default registry name would definitely be useful. For example, I can see how me as a platform engineer would provide my developers with a spin template that would contain a few of these defaults, to make it easy to build things in CI smoothly.

Sadly I'm no rust developer so I won't be able to help out with any development, but I'm happy to help out with beta testing and reading docs.