Add support for notification templates

[FrenchBen]

When working with a notification, an established format has been created, which doesn't provide much flexibility in the message notification.
This is especially relevant for notifiers that support markdown, yet it's set to a default of text:
https://github.com/fluxcd/notification-controller/blob/main/internal/notifier/discord.go#L96
https://github.com/fluxcd/notification-controller/blob/main/internal/notifier/rocket.go#L88
https://github.com/fluxcd/notification-controller/blob/main/internal/notifier/slack.go#L109

Can we create some common template struct to allow more flexibility in the message displayed?

[phillebaba]

This might work but would mean opening up the go template pandoras box which will be difficult to close if it turns out it does not work. We would need to standardize which variables are exposed, which may lead to feature creep as users ask for more and more features in the templating. Saying that I am more in support of this feature than I am against.

I think implementing this might solve #194.

[mbrancato]

Wanted to throw some support on this. I think since already there is a well defined data object (event) being templated using format strings, this would be easy to implement a basic POC.

https://github.com/fluxcd/pkg/blob/11abd078e26f7eaf8c4c415fa1897e1d41993592/runtime/events/event.go#L36-L72

What I'd suggest is that the first implementation of this exposes this object for templating support.

[FrenchBen]

Glad to see others are in favor of this.
How bad is this go template pandora's box?

[hkuersten]

I, too, would love to have a little bit more flexibility in constructing the message sent to Slack: we use the same channel for all notifications from our various environments (dev, QA, Staging and Prod) and if the message is always

kustomization/some-app.flux-system
Deployment/some-app/some-app-deployment configured
revision
master/abc12345def678

Would it be possible to add at least some info on the cluster, from which the event was emitted?

[somtochiama]

@hkuersten There is a spec.summary field in the alert resource that you use to add more info to the alert

[mathieubergeron]

It would also be nice to be able to customize the body being sent when using the generic provider.

I was hoping that using the generic provider would allow me to send a repository_dispatch request to a GitHub repository, but it won't work unless I can specify a valid body for the request.

Edit: For GitHub repository_dispatch, see https://fluxcd.io/flux/components/notification/providers/#github-dispatch

[marcuslindfeldt]

This feels like an essential feature for the notification controller.
To be effective, notifications need to be easy to read and contain just enough information to be informative.
Exactly what that information is will vary in different organisations.

The event object looks promising. If its intent is something else then maybe its possible to create a new object with a very strict api from the beginning and then adding to it later on?

Github actions solved this nicely with the ${github} context object I think.

[Adonisbruno]

UP!
I'm trying customize helmrelease notifcation.

At image Update Automation I want modify template..

imageupdateautomation/flux-system.review
Committed and pushed change 2a70b3c6b39e2214e26ed3f5dae9999f2466526f to main

Images:
XXXXXXXX.com.br/api-arquivo/review:0.4.2-2

I wanted the result to be like this:

helmrelease/api-arquivo.review
Helm upgrade has started

revision
0.3.3

Image
XXXXXXXX.com.br/api-arquivo/review:0.4.2-2

I already tried using summary and eventMetadata:

helmrelease/api-arquivo.review
Helm upgrade succeeded

revision
0.2.8

summary
{{- with index .Event.Metadata "images" -}}
{{- $tag := last (split ":" (index . 0)) -}}
{{- printf "Upgrade %s/%s %s %s." .Values.namespace .Values.nameApp (index .Event.InvolvedObject.Fields "revision") $tag }}

Still without success, does anyone have any idea how to link the image being updated in the helmRelease message? this in a single message?

[wosc]

I'd very much love being able to template the payload, especially for "generic webhook", because that would open up lots of integrations, e.g. things like sending deployment markers to Honeycomb, setting the currently deployed version in something like Bugsnag, and so on. Having to implement each of those as a custom provider seems (to me at least) to be much more effort than should be necessary. (Also, I'd guess that quite a few of which currently are specialized providers, looking at something like Grafana, for example, could then just as well be "generic webhook" with an appropriate template instead of custom code.)