---
tags: CDEvents, Harbor
---

# Harbor & CDEvents Proposal

## Introduction

The [CDEvents](https://cdevents.dev) project, incubated at the [CD Foundation](https://cd.foundation), aims to standardise the content of events in the continuous delivery space, thus introducing interoperability across different tools.

## Motivation

Harbor recently introduced support for CloudEvents (kudos!), which makes it possible for consumers to watch those events, react to them and/or store them for records.

Using CDEvents as format for the payload of Harbor's events provides interoperability across registries and tools. This is also an opportunity for the Harbor community to crontribute to the CDEvents specification and standard data model.

## Use Cases

- GitOps (ArgoCD): One interesting feature of Argo CD is its ability to react to a new tag being published for an artifact, and automatically trigger a new deployment as well as a new PR to keep the git repo up to date as well. Argo CD today has to rely on polling only; a standard event sent by a registry on PUSH would allow Argo CD to react instantaneously.
> [name=Vadim Bauer] would that also be relevant to FluxCD, should we get them on-board?
- Labelling artifacts. The registry can consume CDEvents from other tools to label artifacts accordingly. For instance, if a set of security scans is completed, Harbor could consume a "TestSuite completed" event to label the tested artifact accordingly

## Design

### Producing Events

The CDEevents specification contains today one event that could be produced by Harbor:
- [artifact published](https://github.com/cdevents/spec/blob/v0.3.0/continuous-integration.md#artifact-published)

More events could be added to CDEvents if needed, for instance:
- artifact pulled
- artifact labelled
- more?
> [name=Vadim Bauer] artifact scanned?
more
TBD - need input from Harbor community

### Consuming Events

Harbor could consume CDEvents as well.
There are two quite different routes that can be followed here:
1. Harbor defines an opinionated and fixed list of use cases, which provides users with some limited configuration capabilities. E.g. on "testsuiterun completed" event, apply label
1. Harbor gives users a sink where to send events, and defines a generic mechansim for users to specify what should happen when an event is received

Option (1) is more limited, but it may be much easier to implement.
Option (2) is more powerful, however it may require significant more effort to be implemented. External componets could also be used to achieve (2).

TBD - need input from Harbor community

## Technical Implementation

TBD - need input from Harbor community