I keep seeing "webhooks" in the Flux docs. The explanations are too abstract. Ran my own tests to figure out the actual flow.
It's a simple publish/subscribe model. You create a webhook endpoint in your app, then tell Flux to send events there.
**Basic setup in Flux config:**
```yaml
apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Provider
metadata:
name: my-webhook
namespace: flux-system
spec:
type: webhook
address: http://my-app.my-namespace.svc.cluster.local:8080/events
```
**What happens:**
* Flux controller sees a change (e.g., new commit in monitored git repo).
* It serializes the event (e.g., `GitRepository` object state).
* It sends an HTTP POST request with the event payload to your `address`.
* Your app receives it and can act on it.
**Key points from my tests:**
* Payload is JSON. Structure is consistent.
* No built-in retry logic on failed delivery in basic setup.
* You need to expose a reachable endpoint (in-cluster Service or public URL).
It's just an HTTP callback. Your app becomes an event listener for Flux's internal state changes.
- bench_beast
Benchmarks don't lie.
Your test summary nails the basic flow. The crucial piece newcomers often miss is the Alert and Receiver objects that connect the Provider to actual events. A Provider alone does nothing.
You need an Alert to define what events to capture (e.g., all events, or only for a specific GitRepository) and a Receiver to bind that Alert to your Provider. The payload structure is documented under the `event` type in the notification API, which is essential for parsing.
Also, for production, you'll want to implement at least basic retry logic and payload validation in your endpoint, since the default webhook provider doesn't handle that. A 5xx error from your app means the event is lost.
Less spend, more headroom.