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

     1  The trigger defines the condition when the notification should be sent. The definition includes name, condition
     2  and notification templates reference. The condition is a predicate expression that returns true if the notification
     3  should be sent. The trigger condition evaluation is powered by [antonmedv/expr](https://github.com/antonmedv/expr).
     4  The condition language syntax is described at [language-definition.md](https://github.com/antonmedv/expr/blob/master/docs/language-definition.md).
     5  
     6  The trigger is configured in the `argocd-notifications-cm` ConfigMap. For example the following trigger sends a notification
     7  when application sync status changes to `Unknown` using the `app-sync-status` template:
     8  
     9  ```yaml
    10  apiVersion: v1
    11  kind: ConfigMap
    12  metadata:
    13    name: argocd-notifications-cm
    14  data:
    15    trigger.on-sync-status-unknown: |
    16      - when: app.status.sync.status == 'Unknown'     # trigger condition
    17        send: [app-sync-status, github-commit-status] # template names
    18  ```
    19  
    20  Each condition might use several templates. Typically, each template is responsible for generating a service-specific notification part.
    21  In the example above, the `app-sync-status` template "knows" how to create email and Slack notification, and `github-commit-status` knows how to
    22  generate the payload for GitHub webhook.
    23  
    24  ## Conditions Bundles
    25  
    26  Triggers are typically managed by administrators and encapsulate information about when and which notification should be sent.
    27  The end users just need to subscribe to the trigger and specify the notification destination. In order to improve user experience
    28  triggers might include multiple conditions with a different set of templates for each condition. For example, the following trigger
    29  covers all stages of sync status operation and use a different template for different cases:
    30  
    31  ```yaml
    32  apiVersion: v1
    33  kind: ConfigMap
    34  metadata:
    35    name: argocd-notifications-cm
    36  data:
    37    trigger.sync-operation-change: |
    38      - when: app.status?.operationState.phase in ['Succeeded']
    39        send: [github-commit-status]
    40      - when: app.status?.operationState.phase in ['Running']
    41        send: [github-commit-status]
    42      - when: app.status?.operationState.phase in ['Error', 'Failed']
    43        send: [app-sync-failed, github-commit-status]
    44  ```
    45  
    46  
    47  ## Accessing Optional Manifest Sections and Fields
    48  
    49  Note that in the trigger example above, the `?.` (optional chaining) operator is used to access the Application's
    50  `status.operationState` section. This section is optional; it is not present when an operation has been initiated but has not yet
    51  started by the Application Controller.
    52  
    53  If the `?.` operator were not used, `status.operationState` would resolve to `nil` and the evaluation of the
    54  `app.status.operationState.phase` expression would fail.  The `app.status?.operationState.phase` expression is equivalent to
    55  `app.status.operationState != nil ?  app.status.operationState.phase : nil`.
    56  
    57  
    58  ## Avoid Sending Same Notification Too Often
    59  
    60  In some cases, the trigger condition might be "flapping". The example below illustrates the problem.
    61  The trigger is supposed to generate a notification once when Argo CD application is successfully synchronized and healthy.
    62  However, the application health status might intermittently switch to `Progressing` and then back to `Healthy` so the trigger might unnecessarily generate
    63  multiple notifications. The `oncePer` field configures triggers to generate the notification only when the corresponding application field changes.
    64  The `on-deployed` trigger from the example below sends the notification only once per observed Git revision of the deployment repository.
    65  
    66  ```yaml
    67  apiVersion: v1
    68  kind: ConfigMap
    69  metadata:
    70    name: argocd-notifications-cm
    71  data:
    72    # Optional 'oncePer' property ensure that notification is sent only once per specified field value
    73    # E.g. following is triggered once per sync revision
    74    trigger.on-deployed: |
    75      when: app.status?.operationState.phase in ['Succeeded'] and app.status.health.status == 'Healthy'
    76      oncePer: app.status.sync.revision
    77      send: [app-sync-succeeded]
    78  ```
    79  
    80  **Mono Repo Usage**
    81  
    82  When one repo is used to sync multiple applications, the `oncePer: app.status.sync.revision` field will trigger a notification for each commit. For mono repos, the better approach will be using `oncePer: app.status?.operationState.syncResult.revision` statement. This way a notification will be sent only for a particular Application's revision.
    83  
    84  ### oncePer
    85  
    86  The `oncePer` field is supported like as follows.
    87  
    88  ```yaml
    89  apiVersion: argoproj.io/v1alpha1
    90  kind: Application
    91  metadata:
    92    annotations:
    93      example.com/version: v0.1
    94  ```
    95  
    96  ```yaml
    97  oncePer: app.metadata.annotations["example.com/version"]
    98  ```
    99  
   100  ## Default Triggers
   101  
   102  You can use `defaultTriggers` field instead of specifying individual triggers to the annotations.
   103  
   104  ```yaml
   105  apiVersion: v1
   106  kind: ConfigMap
   107  metadata:
   108    name: argocd-notifications-cm
   109  data:
   110    # Holds list of triggers that are used by default if trigger is not specified explicitly in the subscription
   111    defaultTriggers: |
   112      - on-sync-status-unknown
   113  
   114    defaultTriggers.mattermost: |
   115      - on-sync-running
   116      - on-sync-succeeded
   117  ```
   118  
   119  Specify the annotations as follows to use `defaultTriggers`. In this example, `slack` sends when `on-sync-status-unknown`, and `mattermost` sends when `on-sync-running` and `on-sync-succeeded`.
   120  
   121  ```yaml
   122  apiVersion: argoproj.io/v1alpha1
   123  kind: Application
   124  metadata:
   125    annotations:
   126      notifications.argoproj.io/subscribe.slack: my-channel
   127      notifications.argoproj.io/subscribe.mattermost: my-mattermost-channel
   128  ```
   129  
   130  ## Functions
   131  
   132  Triggers have access to the set of built-in functions.
   133  
   134  Example:
   135  
   136  ```yaml
   137  when: time.Now().Sub(time.Parse(app.status?.operationState.startedAt)).Minutes() >= 5
   138  ```
   139  
   140  {!docs/operator-manual/notifications/functions.md!}