github.com/argoproj/argo-cd/v2@v2.10.9/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 ## Avoid Sending Same Notification Too Often 47 48 In some cases, the trigger condition might be "flapping". The example below illustrates the problem. 49 The trigger is supposed to generate a notification once when Argo CD application is successfully synchronized and healthy. 50 However, the application health status might intermittently switch to `Progressing` and then back to `Healthy` so the trigger might unnecessarily generate 51 multiple notifications. The `oncePer` field configures triggers to generate the notification only when the corresponding application field changes. 52 The `on-deployed` trigger from the example below sends the notification only once per observed Git revision of the deployment repository. 53 54 ```yaml 55 apiVersion: v1 56 kind: ConfigMap 57 metadata: 58 name: argocd-notifications-cm 59 data: 60 # Optional 'oncePer' property ensure that notification is sent only once per specified field value 61 # E.g. following is triggered once per sync revision 62 trigger.on-deployed: | 63 when: app.status.operationState.phase in ['Succeeded'] and app.status.health.status == 'Healthy' 64 oncePer: app.status.sync.revision 65 send: [app-sync-succeeded] 66 ``` 67 68 **Mono Repo Usage** 69 70 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. 71 72 ### oncePer 73 74 The `oncePer` filed is supported like as follows. 75 76 ```yaml 77 apiVersion: argoproj.io/v1alpha1 78 kind: Application 79 metadata: 80 annotations: 81 example.com/version: v0.1 82 ``` 83 84 ```yaml 85 oncePer: app.metadata.annotations["example.com/version"] 86 ``` 87 88 ## Default Triggers 89 90 You can use `defaultTriggers` field instead of specifying individual triggers to the annotations. 91 92 ```yaml 93 apiVersion: v1 94 kind: ConfigMap 95 metadata: 96 name: argocd-notifications-cm 97 data: 98 # Holds list of triggers that are used by default if trigger is not specified explicitly in the subscription 99 defaultTriggers: | 100 - on-sync-status-unknown 101 102 defaultTriggers.mattermost: | 103 - on-sync-running 104 - on-sync-succeeded 105 ``` 106 107 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`. 108 109 ```yaml 110 apiVersion: argoproj.io/v1alpha1 111 kind: Application 112 metadata: 113 annotations: 114 notifications.argoproj.io/subscribe.slack: my-channel 115 notifications.argoproj.io/subscribe.mattermost: my-mattermost-channel 116 ``` 117 118 ## Functions 119 120 Triggers have access to the set of built-in functions. 121 122 Example: 123 124 ```yaml 125 when: time.Now().Sub(time.Parse(app.status.operationState.startedAt)).Minutes() >= 5 126 ``` 127 128 {!docs/operator-manual/notifications/functions.md!}