Update the base structure of a notification

[fabidick22]

Describe the feature

Update the structure of a default notification to add the version of the service (deployment).

Currently, multiple releases of a service create multiple notifications from the same Canary and this creates confusion in the teams that are constantly looking at the alerts, adding the version of the service cloud mitigate this, making it easier to separate a group of alerts for a specific version.

Proposed solution

Adding a new attribute (optional) for the service version on the Canary resource (spec.targetRef) can allow us to update the event notification. Example:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: podinfo
  namespace: test
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: podinfo
    appVersion: v1.2.1

The current structure of a notification is:

podinfo.test New Deployment detected, initialization completed. Target ...

The new structure would be something like this:

podinfo.test:v1.2.1 New Deployment detected, initialization completed. Target ...

Considerations

• We probably need to upgrade the base structure of a notification (example: slack).
• We need to update the base template of all providers (slack, teams, discord, etc.).
• In order not to manually update the version attribute, we should suggest using imagepolicy which is available in Flux.

Any alternatives you've considered?

I'n no sure if the solution described above is the best solution, but another solution can be to add this information in the manifests labels (metadata.labels) so we could create a new field in the default template that adds all the information added in metadata.labels (Canary resource), something like:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: podinfo
  namespace: test
  labels:
    app.kubernetes.io/version: v1.1.1
spec:
  provider: kubernetes
  ...

and the notification would look something like:

podinfo.test New Deployment detected, initialization completed. Metadata

• app.kubernetes.io/version: v1.1.1

Target Deployment/podinfo.test Failed checks threshold 2 Progress deadline 60s Traffic routing Blue/Green

I think I can create a PR for this, but I would like to know what is the best solution.