docs(conventions): define artefact-linking label convention - #146
docs(conventions): define artefact-linking label convention#146bedirhan-yilmaz wants to merge 3 commits into
Conversation
…ationships Signed-off-by: Bedirhan Yilmaz (bedirhan-yilmaz) <bedirhan.yilmaz@sap.com>
Signed-off-by: Bedirhan Yilmaz (bedirhan-yilmaz) <bedirhan.yilmaz@sap.com>
| type: sbom | ||
| extraIdentity: | ||
| architecture: arm64 | ||
| labels: |
There was a problem hiding this comment.
- name: ocm.software/artefactReferences # check whether we want different conventions than camel case
version: v1
value:
- identity:
name: my-image
version: 1.2.3
foo: bar
metadata: # once we need it
There was a problem hiding this comment.
even for in-house labels, we might want to prefix with ocm.software
There was a problem hiding this comment.
If we want to follow conventions on K8s annotations & labels, it would be good to have ocm.software as a prefix :-)
…e structure Signed-off-by: Bedirhan Yilmaz (bedirhan-yilmaz) <bedirhan.yilmaz@sap.com>
ee2a87e to
ef044c9
Compare
|
Since the K8S docs and ODG labels uses kebab-case, I suggest we take the same approach for the label format |
| ### Label Name | ||
|
|
||
| ``` | ||
| ocm.software/artefact-references |
There was a problem hiding this comment.
nit: Do we think we will move towards a new spec version with artifacts instead of resources and sources soon? Currently, it seems rather like we will deprecate sources and keep the rest of the spec. So maybe ocm.software/resource-references would be more fitting?
| - The set of additional key-value pairs MUST exactly match the subject's `extraIdentity`: | ||
| every key in the `identity` entry MUST be present and equal in the subject's `extraIdentity`, | ||
| and the subject's `extraIdentity` MUST NOT contain any keys not present in the `identity` entry. | ||
| 5. Resources that pass all checks are companions of the subject. |
There was a problem hiding this comment.
nit: the term "companion" is used nowhere else to describe this relationship, might be confusing
|
|
||
| ```regexp | ||
| [a-z][a-zA-Z0-9]* | ||
| ocm\.software/[a-z][a-z0-9-]* |
There was a problem hiding this comment.
Do we think this regex is sufficient? Maybe we rather mention that our guidance is to confirm to the k8s label syntax and character set (and not even specify a concrete regex).
| and is appended, separated by a slash (`/`). | ||
| organization (for example `odg.ocm.software/binary-scan-policy`). | ||
| The local name MUST use kebab-case and is appended, separated by a slash (`/`). | ||
|
|
There was a problem hiding this comment.
nit: might want to restructure a little bit as the dns prefix convention now also applies to the predefined labels
What this PR does / why we need it
Adds a convention to the OCM spec for expressing cross-artefact relationships via labels. This allows a derived resource (e.g. an SBoM) to declare which subject resource it relates to within the same component version, using a structured label placed on the derived artefact.
Which issue(s) this PR is related to
Fixes open-component-model/open-delivery-gear#126