eventv1.MetaTokenKey is required to be considered in rate limiting but
it is only for internal use by flux components and should not be sent to
the alert provider. Remove eventv1.MetaTokenKey from the metadata of
event before processing the event for various matching alerts.
Signed-off-by: Sunny <darkowlzz@protonmail.com>
The provider address is already capped at 2048 bytes in the CRD and
this commit adds the same upper limit when reading the address from a
Secret.
Signed-off-by: Max Jonas Werner <mail@makk.es>
Use the context containing proper information about the event for
logging. Previously, the logged error didn't contain any information
about the event, alert or the involved object.
Signed-off-by: Sunny <darkowlzz@protonmail.com>
Emit events in the event handler along with logs on the respective alert
to make the message visible on the alert it belongs to.
Signed-off-by: Sunny <darkowlzz@protonmail.com>
- Break down the EventServer.handleEvent() implementation into multiple
smaller functions which are extensively tested on their own.
- New implementation of filter Alerts for Event
- New implementation of Event matches Alert
- Remove any readiness check on Alert or Provider.
- Add kubebuilder marker for generating RBAC permissions to create and
patch events, and query Alert and Provider objects.
- Convert the event handler test from controllers/ dir to work with
just EventServer without any reconciler, keeping all the test cases
and slightly modified test set up code.
Signed-off-by: Sunny <darkowlzz@protonmail.com>
This to prevent collisions between different event attributes.
For example when first an event with revision `foo` is received
without a token, after which a token `foo` is received without a
revision.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
Use `.status.webhookPath` as a key to index Receivers. Use this key
while listing Receivers during the handling of a payload.
Signed-off-by: Sanskar Jaiswal <jaiswalsanskar078@gmail.com>
This commit bumps the Receiver API version to v1 in preparation of
the Flux GitOps GA milestone
(https://fluxcd.io/roadmap/#flux-gitops-ga-q1-2023).
We are now actively maintaining two versions of the notification API
group in parallel: v1 which currently only holds the Receiver kind and
v1beta2 for all other kinds.
Since we haven't run into this situation before, I had to change the
way we expose the API docs in ./docs/api: The directory now has
sub-directories for each active API version. Therefore we need to
change our scripts in the website repository to take this change into
account so that we expose both API group version at
https://fluxcd.io/flux/components/notification/api/. This change is
implemented in https://github.com/fluxcd/website/pull/1427.
refs #436
Signed-off-by: Max Jonas Werner <mail@makk.es>
Use the Provider cluster assigned UID to compose a unique commit status
ID to avoid name collisions when multiple clusters write to the same
repository.
Signed-off-by: Stefan Prodan <stefan.prodan@gmail.com>