Artifacts in CDEvents are described as the product of a build.
The current artifact subject data model is:
Field | Type | Description | Examples |
---|---|---|---|
id | String |
The ID is in pURL format | pkg:oci/myapp@sha256%3A0b31b1c02ff458ad9b7b81cbdf8f028bd54699fa151f221d1e8de6817db93427 , pkg:golang/mygit.com/myorg/myapp@234fd47e07d1004f0aed9c |
source | URI-Reference |
The source of the artifact (if different from the source of the event) | staging/tekton , tekton-dev-123 |
change | object |
A reference to the change (tag, commit, revision) of the repository which was used to build the artifact" | {"id": "527d4a1aca5e8d0df24813df5ad65d049fc8d312", "source": "my-git.example/an-org/a-repo"} , {"id": "feature1234", "source": "my-git.example/an-org/a-repo"} |
signature | string |
The signature of the artifact | MEYCIQCBT8U5ypDXWCjlNKfzTV4KH516/SK13NZSh8znnSMNkQIhAJ3XiQlc9PM1KyjITcZXHotdMB+J3NGua5T/yshmiPmp |
Domain | Event | Description |
---|---|---|
Artifact | Deployed | The Webhook is triggered when an artifact is deployed to a repository. You can select the repositories and repository paths on which the Webhook will be applied. |
Artifact | Deleted | The Webhook is triggered when an artifact is deleted from a repository. You can select the repositories on which the Webhook will be applied. |
Artifact | Moved | The Webhook is triggered when an artifact is moved from a repository. You can select the repositories and repository paths on which the Webhook will be applied. The Webhook will apply on the repositories from which the artifact is moved. |
Artifact | Copied | The Webhook is triggered when an artifact is copied from a repository. You can select the repositories and repository paths on which the Webhook will be applied. The Webhook will apply on the repositories from which the artifact is copied. |
Artifact | Cached | The Webhook is triggered for each artifact that is pulled from a new remote repository. Webhooks are generated when downloading remote artifacts, for example: npm install busybox. If a webhook can be generated for push replication and the downloading of a remote artifact then it should also work for pull replication as well. |
Artifact Properties | Added | The Webhook is triggered when a property is added to an artifact/folder in a repository, or the repository itself. You can select the repositories and repository paths on which the Webhook will be applied. |
Artifact Properties | Deleted | The Webhook is triggered when a property is deleted from an artifact/folder in a repository, or the repository itself. You can select the repositories and repository paths on which the Webhook will be applied. |
Docker | Pushed | The Webhook is triggered when a new tag of a Docker image is pushed to a Docker repository. You can select the Docker repositories and repository paths on which the Webhook will be applied. |
Docker | Deleted | The Webhook is triggered when a tag of a Docker image is deleted from a Docker repository. You can select the Docker repositories and repository paths on which the Webhook will be applied. |
Docker | Promoted | The Webhook is triggered when a tag of a Docker image is promoted. You can select the Docker repositories and repository paths on which the Webhook will be applied. The Webhook will apply on the Docker repositories from which the Docker tag was promoted. |
Build | Uploaded | The Webhook is triggered when a new build is uploaded. You can select the build names or build patterns on which the Webhook will be applied. |
Build | Deleted | The Webhook is triggered when a build is deleted. You can select the build names or build patterns on which the Webhook will be applied. |
Build | Promoted | The Webhook is triggered when a build is promoted. You can select the build names or build patterns on which the Webhook will be applied. |
Release Bundle | Created | The Webhook is triggered when a Release Bundle is created. You can select the Release Bundle names or patterns on which the Webhook will be applied. |
Release Bundle | Signed | The Webhook is triggered when a Release Bundle is signed. You can select the Release Bundle names or patterns on which the Webhook will be applied. |
Release Bundle | Deleted | The Webhook is triggered when a Release Bundle is deleted. You can select the Release Bundle names or patterns on which the Webhook will be applied. |
Distribution | Started | The Webhook is triggered when Release Bundle distribution has started. |
Distribution | Completed | The Webhook is triggered when Release Bundle distribution has completed. |
Distribution | Aborted | The Webhook is triggered when Release Bundle distribution has completed. |
Distribution | Failed | The Webhook is triggered when Release Bundle distribution has failed. |
Distribution | Deletion Started | The Webhook is triggered when a Release Bundle version deletion has started on one or more Edge nodes. |
Distribution | Deletion Completed | The Webhook is triggered when a Release Bundle version deletion has completed from one or more Edge nodes. |
Distribution | Deletion Failed | The Webhook is triggered when a Release Bundle version deletion has failed on one or more Edge nodes. |
Destination | Received | The Webhook is triggered when a Release Bundle was received on an Edge Node. |
Destination | Delete Started | The Webhook is triggered when a Release Bundle deletion from an Edge Node completed. |
Destination | Delete Completed | The Webhook is triggered when a Release Bundle deletion from an Edge Node completed. |
Destination | Delete Failed | The Webhook is triggered when a Release Bundle deletion from an Edge Node fails. |
Event | Webhook Event Type | Contents of Notification |
---|---|---|
Push artifact to registry | PUSH_ARTIFACT |
Repository namespace name, repository name, resource URL, tags, manifest digest, artifact name, push time timestamp, username of user who pushed artifact |
Pull artifact from registry | PULL_ARTIFACT |
Repository namespace name, repository name, manifest digest, artifact name, pull time timestamp, username of user who pulled artifact |
Delete artifact from registry | DELETE_ARTIFACT |
Repository namespace name, repository name, manifest digest, artifact name, artifact size, delete time timestamp, username of user who deleted image |
Artifact scan completed | SCANNING_COMPLETED |
Repository namespace name, repository name, tag scanned, artifact name, number of critical issues, number of major issues, number of minor issues, last scan status, scan completion time timestamp, username of user who performed scan |
Artifact scan stopped | SCANNING_STOPPED |
Repository namespace name, repository name, tag scanned, artifact name, scan status |
Artifact scan failed | SCANNING_FAILED |
Repository namespace name, repository name, tag scanned, artifact name, error that occurred, username of user who performed scan |
Project quota exceeded | QUOTA_EXCEED |
Repository namespace name, repository name, tags, manifest digest, artifact name, push time timestamp, username of user who pushed artifact |
Project quota near threshold | QUOTA_WARNING |
Repository namespace name, repository name, tags, manifest digest, artifact name, push time timestamp, username of user who pushed artifact |
Artifact replication status changed | REPLICATION |
Repository namespace name, repository name, tags, manifest digest, artifact name, push time timestamp, username of user who trigger the replication |
Artifact tag retention finished | TAG_RETENTION |
Repository namespace name, repository name, the number of total and retained, the rule of retention, deleted artifacts results |
- Carmit:
- Events produced by an artifact registry
- bundling of artifacts
- promotion of artifacts/bundles
- distribution
- release
- Dan:
- Tagging of artifacts as event
- Carmit:
- Generally events should contain only event data
- More data about the artifact can be pulled via APIs
- Emil: What is the bundling of events specifically
- Carmit: a bundle is a group of artifacts (like docker image, helm chart etc), a bundle can inculde up to 1k artifacts
- (Andrea) Create initial tickets to track the events
- Link issues about events to artifact registries
- https://github.com/cdevents/spec/issues/143
- Artifact pull/pushed/deleted but also moved (for artifactory)
- Artifact scanning events are security type of events and should be produced by the tool the perform the security scan
- Quota events in Harbor may not be good candidates for CDEvents
- Archiving may be relevant from an audit trail point of view, less relevant from and SDLC point of view
- Tags could be used to indicate that an artifact is ready for promotion or deployment
- Emil: start a document about events from registries
- Capture events for different artifact registry
- Collaborate on the document
- Use this document as input for the specification work
- Create a slack channel for artifact registry specific discussions