label images with opencontainers 'source' label

[jmtd]

Amongst other things, this allows GitHub to provide links back from Container Images to the source repository that built them (if we publish Container Images to GHCR.) See
https://github.com/opencontainers/image-spec/blob/main/annotations.md#pre-defined-annotation-keys

https://issues.redhat.com/browse/OPENJDK-4003

[jerboaa]

Shouldn't these be links to this instead?

https://github.com/rh-openjdk/redhat-openjdk-containers/tree/ubi9

[jmtd]

That's a good idea (identifying the branch). That form of URI is suitable for humans but not automation (I don't think you could git clone it). The specification is ambiguous) as to whether it should be cloneable or not; it refers back to the older label schema spec which is also not 100% clear, it says "URL for the source code under version control from which this container image was built.". The key in the old spec was labelled vcs-uri, that's borrowed from Debian packaging, in which the intent is for it to be cloneable. (I think it was me that suggested those labels in the older spec, but I might be remembering wrong).

There's a separate org.opencontainers.image.revision label, "Source control revision identifier for the packaged software". If we put ubi9 in that, and left the current label as-is, the original label would be cloneable but it would be unambigious what ref to use. WDYT?

[jerboaa]

There's a separate org.opencontainers.image.revision label, "Source control revision identifier for the packaged software". If we put ubi9 in that, and left the current label as-is, the original label would be cloneable but it would be unambigious what ref to use. WDYT?

That should work, yes.

[jerboaa]

Ideally we'd have a tag for each version and refer to it in org.opencontainers.image.version. E.g. ubi9-1.24 and use that as a tag once released.

[jmtd]

I tag releases as e.g. ubi9-openjdk-containers-1.XX, but it's a manual process and I don 't do it until we've shipped the corresponding release. But we could use that, yeah

[jmtd]

I've not added version (yet) because of a chicken-and-egg problem: it would refer to a tag that doesn't (and can't) exist until the value has been written into the YAML, since that commit would be what the tag would reference.