Event type extensions for adopting tools

[afrittoli]

Tools that adopt CDEvents may already have a set of events that they generate, and some of the existing events may not have a corresponding one in CDEvents.

In some cases it may be possible to add those events into the spec, however, in other cases, it may not be an option, as the events in question may be product-specific and (or) not relevant from an interoperability point of view.

CDEvents should provide a mechanism for such tools to adopt CDEvents without having to renounce those custom events and without having to ask consumers to adopt different SDKs for different event types.

A possible solution could be:

• Define a dev.cdeventsx namespace
• Tools MUST use that namespace to define their custom events
• The event types MUST follow the following rules:
  • The overall structure must be compatible with https://github.com/cdevents/spec/blob/v0.3.0/spec.md#type-context, expect for the dev.cdeventsx namespace instead of dev.cdevents
  • The subject MUST be in the format <tool-name>-<subject-name> to avoid conflicts across tools
• Tools MAY host the schema for the events
• The CDEvents SDK must be able to parse partially custom events, validating the context part and returning a raw payload for the subject

[e-backmark-ericsson]

This somewhat relates to #91 and #147

[afrittoli]

Indeed, this is a duplicate of #147 (I forgot that I filed that already) and related to #91, as having a link to the schema is especially interesting for custom events.

[afrittoli]

To provide an example, this is the list of events provided by Harbor:

We should be able to support all artifact.* events, and I think we could support the scanning.* events too, but I don't think we should adopt the quota, tag retention and replication events, as they seem to be Habor operational events, and not applicable for interoperability use cases.

[afrittoli]

Related to #143 and #144 too.

[afrittoli]

In #172 I'm proposing a few new CDEvents:

• artifact pulled
• artifact deleted

I plan to add an artifact scanned events, that through different outcomes will cover the three scanning events.
I don't see however CDEvents adopting operational events like "Quota near threshold", "Quota exceeded", "Replication statuts changed" or "Tag retention finished". These four could be implemented by Harbor using the dev.cdeventsx.harbor namespace.

What I'm proposing with this issue is to:

• document in the spec that dev.cdeventsx.<tool-name> is the recommended way to add non-interoperability related events
• (optionally): support parsing the context of dev.cdeventsx events in the SDKs
• (optionally): support a schema field in the context so that the schema for custom events may be supplied - see Add a schema uri property to the context #91

[e-backmark-ericsson]

Would we also need to book the domain name "cdeventsx.dev" if that is the naming convention we should follow?