github.com/argoproj/argo-cd/v3@v3.2.1/docs/operator-manual/notifications/examples.md (about)

     1  Here you can find some examples of what you can do with the notifications service in Argo CD.
     2  
     3  ## Getting notified when a sync occurs and understanding how your resources changed
     4  
     5  With Argo CD you can build a notification system that tells you when a sync occurred and what it changed. 
     6  To get notified via webhook when a sync occurs you can add the following trigger:
     7  
     8  ```yaml
     9  apiVersion: v1
    10  kind: ConfigMap
    11  metadata:
    12    name: argocd-notifications-cm
    13  data:
    14    service.webhook.on-deployed-webhook: |
    15      url: <your-webhook-url>
    16      headers:
    17      - name: "Content-Type"
    18        value: "application/json"
    19  
    20    template.on-deployed-template: |
    21      webhook:
    22        on-deployed-webhook:
    23          method: POST
    24          body: |
    25                {{toJson .app.status.operationState.syncResult}}
    26  
    27  
    28    trigger.on-deployed-trigger: |
    29      when: app.status.operationState.phase in ['Succeeded'] and app.status.health.status == 'Healthy'
    30      oncePer: app.status.sync.revision
    31      send: [on-deployed-template]
    32  ```
    33  
    34  This, as explained in the [triggers section](triggers/#avoid-sending-same-notification-too-often), will generate a notification when the app is synced and healthy. We then need to create a subscription for the webhook integration:
    35  
    36  ```yaml
    37  apiVersion: argoproj.io/v1alpha1
    38  kind: Application
    39  metadata:
    40    annotations:
    41      notifications.argoproj.io/subscribe.on-deployed-trigger.on-deployed-webhook: ""
    42  ```
    43  
    44  You can test that this works and see how the response looks by adding any webhook site and syncing our application. Here you can see that we receive a list of resources, with a message and some properties of them. For example:
    45  
    46  ```json
    47  {
    48    "resources": [
    49      {
    50        "group": "apps",
    51        "hookPhase": "Running",
    52        # The images array follows the same order as in the resource yaml
    53        "images": [
    54          "nginx:1.27.1"
    55        ],
    56        "kind": "Deployment",
    57        "message": "deployment.apps/test configured",
    58        "name": "test",
    59        "namespace": "argocd",
    60        "status": "Synced",
    61        "syncPhase": "Sync",
    62        "version": "v1"
    63      },
    64      {
    65        "group": "autoscaling",
    66        "hookPhase": "Running",
    67        "kind": "HorizontalPodAutoscaler",
    68        "message": "horizontalpodautoscaler.autoscaling/test-hpa unchanged",
    69        "name": "test-hpa",
    70        "namespace": "argocd",
    71        "status": "Synced",
    72        "syncPhase": "Sync",
    73        "version": "v2"
    74      }
    75    ],
    76    "revision": "f3937462080c6946ff5ec4b5fa393e7c22388e4c",
    77    ...
    78  }
    79  ```
    80  
    81  We can leverage this information to know:
    82  
    83  1. What resources have changed (not valid for Server Side Apply)
    84  2. How they changed
    85  
    86  To understand what resources changed we can check the message associated with each resource. Those that say that are unchanged were not affected during the sync operation. With the list of changed resources, we can understand how they changed by looking into the images array.
    87  
    88  With this information you can, for example:
    89  
    90  1. Monitor the version of your image being deployed
    91  2. Rollback deployments with images that are known to be faulty within your organisation
    92  3. Detect unexpected image changes: by monitoring the images array in the webhook payload, you can verify that only expected container images are being deployed
    93  
    94  This helps you build a notification system that allows you to understand the status of your deployments in a more advanced manner.
    95  
    96  ## Send the list of images to Slack
    97  
    98  Here we can use a similar setup as the one above, but change the receiver to be Slack:
    99  
   100  ```yaml
   101  apiVersion: v1
   102  kind: ConfigMap
   103  metadata:
   104    name: argocd-notifications-cm
   105  data:
   106  data:
   107    service.slack: |
   108      token: <your-slack-bot-token>
   109  
   110    template.on-deployed-template: |
   111      slack:
   112        message: |
   113          *Deployment Notification*
   114          *Application:* `{{.app.metadata.name}}`
   115          *Namespace:* `{{.app.spec.destination.namespace}}`
   116          *Revision:* `{{.app.status.sync.revision}}`
   117          *Deployed Images:*
   118            {{- range $resource := .app.status.operationState.syncResult.resources -}}
   119              {{- range $image := $resource.images -}}
   120                - "{{$image}}"
   121              {{- end }}
   122            {{- end }}
   123    trigger.on-deployed-trigger: |
   124      when: app.status.operationState.phase in ['Succeeded'] and app.status.health.status == 'Healthy'
   125      oncePer: app.status.sync.revision
   126      send: [on-deployed-template]
   127  ```
   128  
   129  Now, with the setup above, a sync will send the list of images to your Slack application. For more information about integratin with Slack, see the [Slack integration guide](/operator-manual/notifications/services/slack/).
   130  
   131  ### Deduplicating images
   132  
   133  Although the field in `syncResult.resources` contains only resources declared by the user in the GitOps repository you might end up with duplicated images depending on your setup. To avoid having duplicated images, you need to create an external webhook receiver that deduplicates the images, and then send the message to Slack.