owned this note changed 2 years ago
Published Linked with GitHub

Artifacts in CDEvents

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

Events

Events from registries

Artifactory

Available events

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.

Harbour

Available events

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

Notes from the WG Discussion

​​​​- 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
Select a repo