You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
flux2/rfcs/NNNN-cdevents
adamkenihan 0ecbad956d
Create CDEvents RFC
Signed-off-by: adamkenihan <adam.kenihan@est.tech>
10 months ago
..
CDEvents-Flux-RFC-Adapter.png Create CDEvents RFC 10 months ago
CDEvents-Flux-RFC-Broker.png Create CDEvents RFC 10 months ago
Flux-CDEvents-RFC.png Create CDEvents RFC 10 months ago
README.md Create CDEvents RFC 10 months ago
cdevents-flux-tekton.png Create CDEvents RFC 10 months ago

README.md

Flux CDEvents Receiver

Status: provisional

Creation date: 2023-12-08

Last update: 2024-02-09

Summary

The CDEvents Receiver for Flux receives a CDEvent sent to the receiver webhook URL, verifies it and checks the event type against .spec.events, then triggers reconciliation of the configured resources.

Motivation

CDEvents enables interoperability between supported tools in a workflow, and flux is a very popular continuous delivery tool, as such we have received many questions about implementing CDEvents into the tool.

Goals

Integrate CDEvents into Flux with a CDEvents Receiver.

Non-Goals

A CDEvent provider will be handled as a separate RFC in the future.

Proposal

Add CDEvents to the list of available receivers in Flux Notification controller. Similar to other receivers such as the github, the user will be able to use spec.events in order to specify which event types the receiver will allow. The receiver will also verify using the CDEvents Go SDK that the payload sent to the webhook URL is a valid CDEvent.

User Stories

Using Tekton the user triggers something that will fire off a CDEvent to the CloudEvents Broker. A subscription that the user will have set up externally will then send a relevant CDEvent to the CDEvent Receiver within Flux based on the configuration.

usecase

Alternatives

Certain use cases for CDEvents could be done alternatively using available receivers such as the generic webhook.

Design Details

Adding a receiver for CDEvents that works much like the other event-based receivers already implemented. The user will be able to write a yaml file for the receiver and deploy it to their cluster. The receiver takes the payload sent to the webhook URL by an external events broker, checks the headers for the event type, and filters out events based on the user-defined list of events in spec.Events. If left empty, it will act on all valid CDEvents. It then validates the payload body using the CDEvents Go SDK. Valid events will then trigger reconciliation of the resources. The events broker is not a part of this design and is left to the user to set up however they wish.

Example Receiver YAML:

apiVersion: notification.toolkit.fluxcd.io/v1
kind: Receiver
metadata:
  name: cdevents-receiver
  namespace: flux-system
spec:
  type: cdevents
  events:
    - "dev.cdevents.change.merged"
  secretRef:
    name: receiver-token
  resources:
    - kind: GitRespository 
      apiVersion: source.toolkit.fluxcd.io/v1
      name: webapp
      namespace: flux-system

User Flowchart

Adapter

Implementation History