0ecbad956d
Signed-off-by: adamkenihan <adam.kenihan@est.tech> |
10 months ago | |
---|---|---|
.. | ||
CDEvents-Flux-RFC-Adapter.png | 10 months ago | |
CDEvents-Flux-RFC-Broker.png | 10 months ago | |
Flux-CDEvents-RFC.png | 10 months ago | |
README.md | 10 months ago | |
cdevents-flux-tekton.png | 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.
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