Notifications for Argo CD

codecov

Argo CD Notifications

Argo CD Notifications continuously monitors Argo CD applications and provides a flexible way to notify users about important changes in the applications state. The project includes a bundle of useful built-in triggers and notification templates, integrates with various notification services such as Slack, SMTP, Opsgenie, Telegram and anything else using custom webhooks.

demo

Why use Argo CD Notifications?

The Argo CD Notifications is not the only way to monitor Argo CD application. You might leverage Prometheus metrics and Grafana Alerts or projects like bitnami-labs/kubewatch and argo-kube-notifier. The advantage of Argo CD Notifications is that it is focused on Argo CD use cases and ultimately provides a better user experience.

Documentation

Go to the complete documentation to learn more.

Comments
  • notification service 'teams' is not supported

    notification service 'teams' is not supported" Error

    level=info msg="Trigger on-sync-succeeded result: [{[0].zxM90Et6k4Elb1-fHdjtDJq0xR0 [app-sync-succeeded] true}]" app=argocd/prometheus time="2021-04-08T14:38:31Z" level=info msg="Sending notification about condition 'on-sync-succeeded.[0].zxM90Et6k4Elb1-fHdjtDJq0xR0' to '{teams channelName}'" app=argocd/prometheus time="2021-04-08T14:38:31Z" level=error msg="Failed to notify recipient {teams channelName} defined in app argocd/prometheus: notification service 'teams' is not supported" app=argocd/prometheus

    I did install the latest release

  • repo.GetAppDetails() is not working with name/fullnameOverride

    repo.GetAppDetails() is not working with name/fullnameOverride

    Summary

    When used {{(call repo.GetAppDetails).Type}} inside template

    time="2021-06-04T19:06:51Z"
    level=error
    msg="Failed to notify recipient {slack template} defined in app redacted/redacted template: app-sync-running:23:17: executing \"app-sync-running\" at <call .repo.GetAppDetails>: error calling call: rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp: lookup argocd-repo-server on 10.43.0.10:53: no such host\"" app=redacted/redacted
    

    Diagnostics

    I am deploying argo cd + notifications with helm chart with fullnameOverride. argocd-repo-server exists, but named cd-repo-server


    Message from the maintainers:

    Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.

  • Failed to notify recipient for Slack/telegram/email please help me to setup

    Failed to notify recipient for Slack/telegram/email please help me to setup

    1. For Slack I got app token, and have a private channel, but bot is not a member, maybe this is a reason.
    2. For Telegram I created private channel and made my bot an admin. Switched to public - still the same.
    3. not anymore I don't get why * notification service 'email' is not supported* I used the Templates from the catalog

    Install Argo CD Notifications

    kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj-labs/argocd-notifications/release-1.0/manifests/install.yaml
    

    Install Triggers and Templates from the catalog

    kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj-labs/argocd-notifications/release-1.0/catalog/install.yaml
    

    Register notification services

    $ kubectl -n argocd patch secret argocd-notifications-secret --patch-file argocd-notifications-secret.yaml 
    secret/argocd-notifications-secret patched
    
    $ kubectl -n argocd patch cm argocd-notifications-cm --patch-file argocd-notifications-cm.yaml 
    configmap/argocd-notifications-cm patched
    

    Subscribe to notifications

    by adding the notifications.argoproj.io/subscribe.on-sync-succeeded.slack annotation to the Argo CD application or project:

    kubectl patch app ppserver -n argocd -p '{"metadata": {"annotations": {"notifications.argoproj.io/subscribe.on-sync-succeeded.telegram":"Argo Cd Notifications", "notifications.argoproj.io/subscribe.on-sync-succeeded.slack":"phoenix-argo"}}}' --type merge
    kubectl patch app ppserver -n argocd -p '{"metadata": {"annotations": {"notifications.argoproj.io/subscribe.on-sync-succeeded.email.gmail":"[email protected]"}}}' --type merge
    

    Troubles

    time="2021-03-09T16:02:21Z" level=info msg="Sending notification about condition 'on-sync-succeeded.[0].zxM90Et6k4Elb1-fHdjtDJq0xR0' to '{email [email protected]}'" app=argocd/ppserver
    time="2021-03-09T16:02:21Z" level=error msg="Failed to notify recipient {email [email protected]} defined in app argocd/ppserver: notification service 'email' is not supported" app=argocd/ppserver
    time="2021-03-09T16:02:21Z" level=info msg="Sending notification about condition 'on-sync-succeeded.[0].zxM90Et6k4Elb1-fHdjtDJq0xR0' to '{slack phoenix-argo}'" app=argocd/ppserver
    time="2021-03-09T16:02:21Z" level=error msg="Failed to notify recipient {slack phoenix-argo} defined in app argocd/ppserver: channel_not_found" app=argocd/ppserver
    time="2021-03-09T16:02:21Z" level=info msg="Sending notification about condition 'on-sync-succeeded.[0].zxM90Et6k4Elb1-fHdjtDJq0xR0' to '{telegram Argo Cd Notifications}'" app=argocd/ppserver
    time="2021-03-09T16:02:21Z" level=error msg="Failed to notify recipient {telegram Argo Cd Notifications} defined in app argocd/ppserver: Bad Request: chat not found" app=argocd/ppserver
    

    UPD 2021-mar-10 I go with default-subscriptions

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: argocd-notifications-cm
    data:
      service.slack: |
        token: $slack-token
        username: Argo CD # optional username
        icon: https://argocd-notifications.readthedocs.io/en/stable/assets/logo.png # optional icon for the message (supports both emoij and url notation)
      service.telegram: |
        token: $telegram-token
      service.email: |
        username: $email-username
        password: $email-password
        host: smtp.gmail.com
        port: 465
        from: $email-username
      subscriptions: |
        - recipients:
          - slack:phoenix-argo
          - email:[email protected]
          - telegram:Argo Cd Notifications
          triggers:
          - on-sync-status-unknown
          - on-sync-failed
          - on-health-degraded
          - on-deployed
          - on-sync-succeeded
    

    Result

    time="2021-03-10T15:22:45Z" level=error msg="Failed to notify recipient {slack phoenix-argo} defined in app argocd/ingress-controller: channel_not_found" app=argocd/ingress-controller
    time="2021-03-10T15:22:45Z" level=error msg="Failed to notify recipient {email [email protected]} defined in app argocd/ingress-controller: 534 5.7.9 Application-specific password required. Learn more at\n5.7.9  https://support.google.com/mail/?p=InvalidSecondFactor XXXXXXXXXX- gsmtp" app=argocd/ingress-controller
    time="2021-03-10T15:22:45Z" level=error msg="Failed to notify recipient {telegram Argo Cd Notifications} defined in app argocd/ingress-controller: Bad Request: chat not found" app=argocd/ingress-controller
    

    what to do next?

    • gmail 2FA not let me send, ok
    • slack: I am not an admin, TL installed bot @phoenixargo in this channel. As I can see message is added an integration to this channel: phoenix-argo. @phoenixargo has chat:write, chat:write.customize scopes.
    • phoenix-argo is private
    • telegram - same chat not found by its name "Argo Cd Notifications"
    • Argo Cd Notifications is public channel, bot is admin there.
  • Slack notifications with ApplicationSet controller

    Slack notifications with ApplicationSet controller

    Summary

    I've added the notification notifications.argoproj.io/subscribe.on-sync-succeeded.slack: platform-activity to the template section of the ApplicationSet definition. On sync it started bombing my Slack with duplicated notifications. On the ArgoCD GUI I noticed the annotations for the selected Application been updated all the time with something like notification already sent, then this notification disappeared, then another Slack nmessage arrived, annotation updated and disappeared again and again.

    The AppSet config looks like

    apiVersion: argoproj.io/v1alpha1
    kind: ApplicationSet
    metadata:
      name: the-cluster
    spec:
      generators:
        - git:
            repoURL: [email protected]:company/the-cluster.git
            revision: HEAD
            directories:
              - path: apps/*
      template:
        metadata:
          name: "{{path.basename}}"
          annotations:
            notifications.argoproj.io/subscribe.on-sync-succeeded.slack: argocd-activity      
        spec:
          project: default
          source:
            repoURL: [email protected]:company/the-cluster.git
            targetRevision: HEAD
            path: "{{path}}"
          destination:
            server: https://kubernetes.default.svc
            namespace: "{{path.basename}}"
    

    Diagnostics

    What Kubernetes provider are you using?

    • Latest available on Azure AKS

    What version of Argo CD and Argo CD Notifications are you running?

    • Argo CD 2.0
    • Argo CD Notifications v1.0.2
    time="2021-04-28T16:28:58Z" level=info msg="Trigger on-sync-succeeded result: [{[0].zxM90Et6k4Elb1-fHdjtDJq0xR0 [app-sync-succeeded] true}]" app=argocd/ops
    time="2021-04-28T16:28:58Z" level=info msg="Sending notification about condition 'on-sync-succeeded.[0].zxM90Et6k4Elb1-fHdjtDJq0xR0' to '{slack platform-activity}'" app=argocd/ops
    time="2021-04-28T16:28:58Z" level=info msg="Processing completed" app=argocd/ops
    time="2021-04-28T16:28:58Z" level=info msg="Start processing" app=argocd/queuemeter
    time="2021-04-28T16:28:58Z" level=info msg="Trigger on-sync-succeeded result: [{[0].zxM90Et6k4Elb1-fHdjtDJq0xR0 [app-sync-succeeded] true}]" app=argocd/queuemeter
    time="2021-04-28T16:28:58Z" level=info msg="Sending notification about condition 'on-sync-succeeded.[0].zxM90Et6k4Elb1-fHdjtDJq0xR0' to '{slack platform-activity}'" app=argocd/queuemeter
    time="2021-04-28T16:28:58Z" level=info msg="Processing completed" app=argocd/queuemeter
    time="2021-04-28T16:28:58Z" level=info msg="Start processing" app=argocd/ops
    time="2021-04-28T16:28:58Z" level=info msg="Trigger on-sync-succeeded result: [{[0].zxM90Et6k4Elb1-fHdjtDJq0xR0 [app-sync-succeeded] true}]" app=argocd/ops
    time="2021-04-28T16:28:58Z" level=info msg="Notification about condition 'on-sync-succeeded.[0].zxM90Et6k4Elb1-fHdjtDJq0xR0' already sent to '{slack platform-activity}'" app=argocd/ops
    time="2021-04-28T16:28:58Z" level=info msg="Processing completed" app=argocd/ops
    time="2021-04-28T16:28:58Z" level=info msg="Start processing" app=argocd/queuemeter
    time="2021-04-28T16:28:58Z" level=info msg="Trigger on-sync-succeeded result: [{[0].zxM90Et6k4Elb1-fHdjtDJq0xR0 [app-sync-succeeded] true}]" app=argocd/queuemeter
    time="2021-04-28T16:28:58Z" level=info msg="Notification about condition 'on-sync-succeeded.[0].zxM90Et6k4Elb1-fHdjtDJq0xR0' already sent to '{slack platform-activity}'" app=argocd/queuemeter
    time="2021-04-28T16:28:58Z" level=info msg="Processing completed" app=argocd/queuemeter
    time="2021-04-28T16:29:00Z" level=info msg="Start processing" app=argocd/ops
    time="2021-04-28T16:29:00Z" level=info msg="Trigger on-sync-succeeded result: [{[0].zxM90Et6k4Elb1-fHdjtDJq0xR0 [app-sync-succeeded] true}]" app=argocd/ops
    time="2021-04-28T16:29:00Z" level=info msg="Sending notification about condition 'on-sync-succeeded.[0].zxM90Et6k4Elb1-fHdjtDJq0xR0' to '{slack platform-activity}'" app=argocd/ops
    time="2021-04-28T16:29:00Z" level=info msg="Processing completed" app=argocd/ops
    time="2021-04-28T16:29:00Z" level=info msg="Start processing" app=argocd/queuemeter
    time="2021-04-28T16:29:00Z" level=info msg="Trigger on-sync-succeeded result: [{[0].zxM90Et6k4Elb1-fHdjtDJq0xR0 [app-sync-succeeded] true}]" app=argocd/queuemeter
    time="2021-04-28T16:29:00Z" level=info msg="Sending notification about condition 'on-sync-succeeded.[0].zxM90Et6k4Elb1-fHdjtDJq0xR0' to '{slack platform-activity}'" app=argocd/queuemeter
    time="2021-04-28T16:29:00Z" level=info msg="Processing completed" app=argocd/queuemeter
    time="2021-04-28T16:29:00Z" level=info msg="Start processing" app=argocd/ops
    time="2021-04-28T16:29:00Z" level=info msg="Trigger on-sync-succeeded result: [{[0].zxM90Et6k4Elb1-fHdjtDJq0xR0 [app-sync-succeeded] true}]" app=argocd/ops
    time="2021-04-28T16:29:00Z" level=info msg="Notification about condition 'on-sync-succeeded.[0].zxM90Et6k4Elb1-fHdjtDJq0xR0' already sent to '{slack platform-activity}'" app=argocd/ops
    time="2021-04-28T16:29:00Z" level=info msg="Processing completed" app=argocd/ops
    time="2021-04-28T16:29:00Z" level=info msg="Start processing" app=argocd/queuemeter
    time="2021-04-28T16:29:00Z" level=info msg="Trigger on-sync-succeeded result: [{[0].zxM90Et6k4Elb1-fHdjtDJq0xR0 [app-sync-succeeded] true}]" app=argocd/queuemeter
    time="2021-04-28T16:29:00Z" level=info msg="Notification about condition 'on-sync-succeeded.[0].zxM90Et6k4Elb1-fHdjtDJq0xR0' already sent to '{slack platform-activity}'" app=argocd/queuemeter
    time="2021-04-28T16:29:00Z" level=info msg="Processing completed" app=argocd/queuemeter
    time="2021-04-28T16:29:03Z" level=info msg="Start processing" app=argocd/ops
    time="2021-04-28T16:29:03Z" level=info msg="Trigger on-sync-succeeded result: [{[0].zxM90Et6k4Elb1-fHdjtDJq0xR0 [app-sync-succeeded] true}]" app=argocd/ops
    time="2021-04-28T16:29:03Z" level=info msg="Notification about condition 'on-sync-succeeded.[0].zxM90Et6k4Elb1-fHdjtDJq0xR0' already sent to '{slack platform-activity}'" app=argocd/ops
    time="2021-04-28T16:29:03Z" level=info msg="Processing completed" app=argocd/ops
    time="2021-04-28T16:29:03Z" level=info msg="Start processing" app=argocd/ops
    

    Message from the maintainers:

    Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.

  • fix : support HTTP proxy

    fix : support HTTP proxy

    Fixes #42

    Configure the http client in the slackNotifier with the default transport settings.

    It's better not to lose the default transport settings when configuring http.Client, because, without default transport settings, we cannot use a proxy to post messages to slack.

    Thanks :)

  • Support sending the generic webhook request.

    Support sending the generic webhook request.

    Support sending the generic HTTP request with the ability to generate request body using a template. This feature allows provides a way to quickly integrate notification service that does not have first-class support.

    The notification service is not necessary to send messages to a human. It might be Jenkins webhook that triggers a post-deployment test.

    The argocd-notifications-secret allows defining named webhooks under new webhooks field. Each webhook has the url and optional list of headers.

    apiVersion: v1
    kind: Secret
    metadata:
      name: argocd-notifications-secret
    stringData:
      notifiers.yaml: |
        webhook:
          - name: jenkins
            url: https://my-jenkins/webhook
            headers:
              - name: Authorization
                value: <secret-value-here>
    type: Opaque
    

    The webhook can be referenced using webhook:<name> in argocd-notifications.argoproj.io annotation:

    metadata:
      annotations:
        on-sync-succeeded.recipients.argocd-notifications.argoproj.io: webhook:jenkins
    

    The notification template should have the webhook field that allows specifying request method and body.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: argocd-notifications-cm
    data:
        templates:
          - name: jenkins-webhook
            webhook:
              jenkins:
                method: POST # optional, POST is default value
                body: | {
                      "test": "test"
                }
    
  • Annotation greater than 63 characters

    Annotation greater than 63 characters

    Problem

    I've created a webhook that seems to surpassed the 63 char limit on annotations.

    How do I go about referencing my template without breaking Kubernetes?

    I find it interesting as even notifications.argoproj.io/subscribe.on-sync-status-unknown.mattermost would break this.

    Is there a different way to specify this in the Application CRD?

  • I get this log message: `notification service 'slack' is not supported`

    I get this log message: `notification service 'slack' is not supported`

    Hi, I hope you are doing well. I am experimenting argocd-notification on an EKS cluster. I use argocd v1.8.7+eb3d1fb and argocd-notification v1.0.2

    I am trying to get notification sent to my company's slack workspace I have registered a slack application according to https://argocd-notifications.readthedocs.io/en/stable/services/slack/ and the app is registered to my targeted channel

    I have then configured the argocd-notifications-cm config map and the argocd-notifications-secret and registered my argo application to send notification when on-sync-succeeded.

    When I sync my app, I don't get notification in slack. Looking at the log of the pod argocd-notifications-controller-***** I see this message:

    time="2021-03-31T08:02:07Z" level=info msg="Sending notification about condition 'on-sync-succeeded.[0].zxM90Et6k4Elb1-fHdjtDJq0xR0' to '{slack tc-jenkins-aws}'" app=argocd/cloudy-emily-dev
    time="2021-03-31T08:02:07Z" level=error msg="Failed to notify recipient {slack tc-jenkins-aws} defined in app argocd/cloudy-emily-dev: notification service 'slack' is not supported" app=argocd/cloudy-emily-dev
    

    If I execute this command on the pod: argocd-notifications-controller, I get an error, but I check my yaml files for the ConfigMap and the Secret and they look valid.

    $kubectl -n argocd  exec -it argocd-notifications-controller-84ccc64f96-pf42v \
    >   /app/argocd-notifications trigger get
    kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
    failed to parse config: error converting YAML to JSON: yaml: line 2: did not find expected '-' indicator
    

    Can you help me figure out what I did wrong? Thanks in advance for your help

  • I have a question about setting up slack in argocd-notifications-secret's notifiers.yaml.

    I have a question about setting up slack in argocd-notifications-secret's notifiers.yaml.

    Hello! 😃

    I am very interested in your work. I've been waiting for the notification feature on the Argo CD. Thank you for your works!

    Back to the point, so I tried to test your project right away. Back to the point So I tried to test your project right away.

    But setting up Slack is too difficult. I'm wonder that what tokens does mean in the https://argoproj-labs.github.io/argocd-notifications/ documentation? How can I find this token?

    Please Let me know. Thank you.

  • Could not create directory '/home/argocd/.ssh' when using .repo.GetCommitMetadata

    Could not create directory '/home/argocd/.ssh' when using .repo.GetCommitMetadata

    Summary

    I'm unable to produce notifications using repo calls (like .repo.GetCommitMetadata e.g) - it worked single time (and once only) and since then every other try ends with error:

    argocd-notifications-controller-7df6c975f5-qlcm7 argocd-notifications-controller time="2021-11-25T19:58:17Z" level=error msg="Failed to notify recipient {slack argocd-all-alerts} defined in resource argocd/argo-config: template: app-deployed:18:18: executing \"app-deployed\" at <call .repo.GetCommitMetadata .app.status.sync.revision>: error calling call: rpc error: code = Internal desc = Failed to fetch 54bbb5a4c68cabd9f5162179a5512edbb241affb:git fetch origin --tags --forcefailed exit status 128: Could not create directory '/home/argocd/.ssh' (Read-only file system).\r\nFailed to add the ECDSA host key for IP address '51.68.x.xx' to the list of known hosts (/home/argocd/.ssh/known_hosts).\r\[email protected]: Permission denied (publickey).\r\nfatal: Could not read from remote repository.\n\nPlease make sure you have the correct access rights\nand the repository exists." resource=argocd/argo-config

    I've added our private gitlab instance ssh certs by: ssh-keyscan gitlab.xxx.xxx.com | argocd cert add-ssh --batch

    and cert are there which I can view by: argocd cert list --cert-type ssh

    Before I did that (add certs) other error was present - about host being not know. After certs were added I was able to successfully produce notification using .repo calls once (pic) and that's it - every other try ends with above error.

    image

    Diagnostics

    What Kubernetes provider are you using? GCP GKE - v1.21.5-gke.1802

    What version of Argo CD and Argo CD Notifications are you running? Argo CD v2.1.7+a408e2 Argo CD notifications: v.1.2.0

    # Paste the logs from the notification controller
    already pasted above
    
    ---
    <!-- Issue Author: Don't delete this message to encourage other users to support your issue! -->
    **Message from the maintainers**:
    
    Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.
    
  • oncePer option bug

    oncePer option bug

    Hi,All, i have issue with duplicate notifications, i am getting for each commit notification twice I am using oncePer option, but i have no affect to problem. Also this my configuration of trigger

      trigger.on-sync-running: |
        - when: app.status.operationState.phase in ['Running']
          oncePer: app.status.sync.revision
          description: Application is being synced
          send: [app-sync-running]
    
      trigger.on-sync-succeeded: |
        - description: Application syncing has succeeded
          oncePer: app.status.sync.revision
          send:
          - app-sync-succeeded
          when: app.status.operationState.phase in ['Succeeded'] and app.status.health.status == 'Healthy'
    

    And for debug i changed template to

          Debug: {{html .app.metadata.name}}  {{html .app.status.operationState.syncResult.revision}} {{html .app.status.sync.revision}}
    

    And i received this messages 2 notifications in telegram for on-sync-running, as i see oncePer option wasnt worked

    Debug: develop-devops-loki  <no value> 35f3d95bdfe235ebfc9e736fa2ebb0945d6edfa9
    Debug: develop-devops-loki  <no value> 35f3d95bdfe235ebfc9e736fa2ebb0945d6edfa9
    

    And duplicate message for on-sync-succeeded

    Debug: develop-devops-loki  35f3d95bdfe235ebfc9e736fa2ebb0945d6edfa9 35f3d95bdfe235ebfc9e736fa2ebb0945d6edfa9
    Debug: develop-devops-loki  35f3d95bdfe235ebfc9e736fa2ebb0945d6edfa9 35f3d95bdfe235ebfc9e736fa2ebb0945d6edfa9
    
  • Should make argocd-notifications-secret to an optional argument

    Should make argocd-notifications-secret to an optional argument

    Summary

    For webhooks that do not use secrets(like discord), the notification controller should not detect the existence of argocd-notifications-secret

    Diagnostics

    My environment: EKS 1.22 Argocd v2.4.11+3d9e9f2 Argocd notifications v1.2.1

    This is the log without argocd-notifications-secret applied

    time="2022-09-08T14:01:23Z" level=info msg="Start processing" resource=argocd/app
    time="2022-09-08T14:01:23Z" level=error msg="Failed to process: secret \"argocd-notifications-secret\" not found" resource=argocd/app
    

    After adding a empty secret

    apiVersion: v1
    kind: Secret
    metadata:
      name: argocd-notifications-secret
    type: Opaque
    
    

    The controller is available immediately

    time="2022-09-08T14:01:23Z" level=info msg="Start processing" resource=argocd/app
    time="2022-09-08T14:01:23Z" level=info msg="Processing skipped: sync status out of date" resource=argocd/app
    

    I have just used argocd for a short time, so please correct me if my description is technically incorrect.


    Message from the maintainers:

    Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.

  • get triggerName in template

    get triggerName in template

    Summary

    I'm configuring a webhook-forwarder layer for multiple sources and multiple targets.

    so, I made all triggers use same template like this.

      template.app-common: |
        webhook:
          forwarder:
            method: POST
            body: |-
              {
                "app": {
                  "metadata": {
                    "name": "{{.app.metadata.name}}"
                  },
                  "status": {
                    "health": {
                      "status": "{{.app.status.health.status}}"
                    },
                    "operationState": {
                      "operation": {
                        "sync": {
                          "revision": "{{.app.status.operationState.operation.sync.revision}}"
                        }
                      },
                      "finishedAt": "{{.app.status.operationState.finishedAt}}",
                      "message": "{{.app.status.operationState.message}}",
                      "phase": "{{.app.status.operationState.phase}}"
                    },
                    "sync": {
                      "status": "{{.app.status.sync.status}}",
                      "revision": "{{.app.status.sync.revision}}"
                    },
                    "conditions": [
                      {{range $index, $c := .app.status.conditions}}
                      {{if ne $index 0}},{{end}}
                      {
                        "type": "{{$c.type}}",
                        "message": "{{$c.message}}"
                      }
                      {{end}}
                    ]
                  }
                },
                "context": {
                  "argocdUrl": "{{.context.argocdUrl}}"
                }
              }
      trigger.on-deployed:  |
        - when: app.status.operationState.phase in ['Succeeded'] and app.status.health.status == 'Healthy'
          oncePer: app.status.sync.revision
          send: [app-common]
      trigger.on-health-degraded: |
        - when: app.status.health.status == 'Degraded'
          send: [app-common]
      trigger.on-sync-failed: |
        - when: app.status.operationState.phase in ['Error', 'Failed']
          send: [app-common]
      trigger.on-sync-running: |
        - when: app.status.operationState.phase in ['Running']
          send: [app-common]
      trigger.on-sync-status-unknown: |
        - when: app.status.sync.status == 'Unknown'
          send: [app-common]
      trigger.on-sync-succeeded: |
        - when: app.status.operationState.phase in ['Succeeded']
          send: [app-common]
    

    but, in template cannot figure out that what trigger is triggering the webhook.

    I want to get trigger name in template something like this..

      template.app-common: |
        webhook:
          forwarder:
            method: POST
            body: |-
              {
                "app": {
                  "metadata": {
                    "name": "{{.app.metadata.name}}",
                    "trigger": "{{.triggerName}}" // on-sync-failed, on-sync-succeeded ....
                  },
    

    Use Cases

    this feature will be useful when managing a custom webhook template.


    Message from the maintainers:

    Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.

  • ArgoCD Email on-health-degraded does not work

    ArgoCD Email on-health-degraded does not work

    Summary

    Hi team, argocd does not send an email when the health of the application degrades. However it can still send an email on sync success.

    Diagnostics

    What Kubernetes provider are you using? Google Cloud Platform

    What version of Argo CD and Argo CD Notifications are you running?

    argocd: v2.3.4+ac8b7df
      BuildDate: 2022-05-18T13:06:25Z
      GitCommit: ac8b7df9467ffcc0920b826c62c4b603a7bfed24
      GitTreeState: clean
      GoVersion: go1.17.9
      Compiler: gc
      Platform: linux/amd64
    argocd-server: v2.4.0+91aefab
      BuildDate: 2022-06-10T17:23:37Z
      GitCommit: 91aefabc5b213a258ddcfe04b8e69bb4a2dd2566
      GitTreeState: clean
      GoVersion: go1.18.3
      Compiler: gc
      Platform: linux/amd64
      Kustomize Version: v4.4.1 2021-11-11T23:36:27Z
      Helm Version: v3.8.1+g5cb9af4
      Kubectl Version: v0.23.1
      Jsonnet Version: v0.18.0
    

    Config map

     trigger.on-health-degraded: |
        - description: Application has degraded
          send:
          - app-health-degraded
          when: app.status.health.status == 'Degraded'
    
    // No output
    kubectl logs argocd-notifications-controller-69bf646f87-mzmqc -n argocd | grep 'Degraded'
    
    
    argo app list
    NAME                      CLUSTER                         NAMESPACE  PROJECT  STATUS   HEALTH    SYNCPOLICY  CONDITIONS  REPO                     PATH                                         TARGET
    sgdecoding-online-scaled  https://kubernetes.default.svc  production  default  Synced  Degraded  Auto-Prune  <none>      [email protected]:kaikiat/argo-project.git  /helm/sgdecoding-online-scaled  HEAD
    
    

    The health is degraded but no email is sent. I am wondering if anyone have any insights / solutions on this issue. Thank you !


    Message from the maintainers:

    Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.

  • chore(deps): bump github.com/argoproj/argo-cd/v2 from 2.1.7 to 2.1.16

    chore(deps): bump github.com/argoproj/argo-cd/v2 from 2.1.7 to 2.1.16

    Bumps github.com/argoproj/argo-cd/v2 from 2.1.7 to 2.1.16.

    Release notes

    Sourced from github.com/argoproj/argo-cd/v2's releases.

    v2.1.16

    Quick Start

    Non-HA:

    kubectl create namespace argocd
    kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.1.16/manifests/install.yaml
    

    HA:

    kubectl create namespace argocd
    kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.1.16/manifests/ha/install.yaml
    

    Security fixes

    Note: This will be the last security fix release in the 2.1.x series. Please upgrade to a newer minor version to continue to get security fixes.

    Potentially-breaking changes

    From the GHSA-2m7h-86qq-fp4v description:

    The patch introduces a new reposerver.max.combined.directory.manifests.size config parameter, which you should tune before upgrading in production. It caps the maximum total file size of .yaml/.yml/.json files in directory-type (raw manifest) Applications. The default max is 10M per Application. This max is designed to keep any single app from consuming more than 3G of memory in the repo-server (manifests consume more space in memory than on disk). The 300x ratio assumes a maliciously-crafted manifest file. If you only want to protect against accidental excessive memory use, it is probably safe to use a smaller ratio.

    If your organization uses directory-type Applications with very many manifests or very large manifests then check the size of those manifests and tune the config parameter before deploying this change to production. When testing, make sure to do a "hard refresh" in either the CLI or UI to test your directory-type App. That will make sure you're using the new max logic instead of relying on cached manifest responses from Redis.

    Bug fixes

    Other

    • test: directory app manifest generation (#9503)
    • test: fix erroneous test change
    • chore: eliminate go-mpatch dependency (#9045)
    • chore: Make unit tests run on platforms other than amd64 (#8995)
    • chore: remove obsolete repo-server unit test (#9559)
    • chore: upgrade golangci-lint to v1.46.2 (#9448)
    • chore: update golangci-lint (#8988)
    • test: fix ErrorContains (#9445)

    v2.1.15

    ... (truncated)

    Changelog

    Sourced from github.com/argoproj/argo-cd/v2's changelog.

    Changelog

    v2.4.0 (Unreleased)

    Web Terminal In Argo CD UI

    Feature enables engineers to start a shell in the running application container without leaving the web interface. Just find the required Kubernetes Pod using the Application Details page, click on it and select the Terminal tab. The shell starts automatically and enables you to execute the required commands, and helps to troubleshoot the application state.

    Access Control For Pod Logs & Web Terminal

    Argo CD is used to manage the critical infrastructure of multiple organizations, which makes security the top priority of the project. We've listened to your feedback and introduced additional access control settings that control access to Kubernetes Pod logs and the new Web Terminal feature.

    Known UI Issue for Pod Logs Access

    Currently, upon pressing the "LOGS" tab in pod view by users who don't have an explicit allow get logs policy, the red "unable to load data: Internal error" is received in the bottom of the screen, and "Failed to load data, please try again" is displayed.

    OpenTelemetry Tracing Integration

    The new feature allows emitting richer telemetry data that might make identifying performance bottlenecks easier. The new feature is available for argocd-server and argocd-repo-server components and can be enabled using the --otlp-address flag.

    Power PC and IBM Z Support

    The list of supported architectures has been expanded, and now includes IBM Z (s390x) and PowerPC (ppc64le). Starting with the v2.4 release the official quay.io repository is going to have images for amd64, arm64, ppc64le, and s390x architectures.

    Other Notable Changes

    Overall v2.4 release includes more than 300 hundred commits from nearly 90 contributors. Here is a short sample of the contributions:

    • Enforce the deployment to remote clusters only
    • Native support of GCP authentication for GKE
    • Secured Redis connection
    • ApplicationSet Gitea support

    v2.3.3 (2022-03-29)

    • fix: prevent excessive repo-server disk usage for large repos (#8845) (#8897)
    • fix: Set QPS and burst rate for resource ops client (#8915)

    v2.3.2 (2022-03-22)

    • fix: application resource APIs must enforce project restrictions

    v2.3.1 (2022-03-10)

    ... (truncated)

    Commits
    • 903db5f Bump version to 2.1.16
    • 1d26f44 Bump version to 2.1.16
    • e577e25 chore: fix docs gen
    • a92a153 Merge pull request from GHSA-jhqp-vf4w-rpwq
    • 45ddd05 Merge pull request from GHSA-q4w5-4gq2-98vm
    • 947bdd9 Merge pull request from GHSA-2m7h-86qq-fp4v
    • 4fd50ce Merge pull request from GHSA-h4w9-6x78-8vrj
    • 3fab7de fix: missing Helm params (#9565) (#9566)
    • 5e6b788 test: directory app manifest generation (#9503)
    • 26ac321 test: fix erroneous test change
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

    You can disable automated security fix PRs for this repo from the Security Alerts page.

Argo CD ApplicationSet Controller

The ApplicationSet controller manages multiple Argo CD Applications as a single ApplicationSet unit, supporting deployments to large numbers of clusters, deployments of large monorepos, and enabling secure Application self-service.

Dec 14, 2022
Automatic container image update for Argo CD

Argo CD Image Updater Introduction Argo CD Image Updater is a tool to automatically update the container images of Kubernetes workloads which are mana

Dec 25, 2022
A Kubernetes operator for managing Argo CD clusters.

Argo CD Operator A Kubernetes operator for managing Argo CD clusters. Documentation See the documentation for installation and usage of the operator.

Dec 14, 2022
Support for extending Argo CD

Argo CD Extensions To enable Extensions for your Argo CD cluster will require just a single kubectl apply. Here we provide a way to extend Argo CD suc

Dec 20, 2022
Argo-CD Autopilot
Argo-CD Autopilot

Introduction New users to GitOps and Argo CD are not often sure how they should structure their repos, add applications, promote apps across environme

Jan 6, 2023
Hera is a Python framework for constructing and submitting Argo Workflows.

Hera is an Argo Workflows Python SDK. Hera aims to make workflow construction and submission easy and accessible to everyone! Hera abstracts away workflow setup details while still maintaining a consistent vocabulary with Argo Workflows.

Dec 31, 2022
A series of controllers for configuring namespaces to accomodate Argo

argo-controller A series of controllers for configuring namespaces to accomodate Argo. ArgoCD TBD Argo Workflows Make a service account in every names

Jan 4, 2022
Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes.
Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes.

What is Argo Workflows? Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Argo Workflow

Dec 10, 2021
Notifications for Argo CD
Notifications for Argo CD

Argo CD Notifications Argo CD Notifications continuously monitors Argo CD applications and provides a flexible way to notify users about important cha

Nov 27, 2022
Github-notifications - Small script to alert me when I have notifications on Github. I use it in my Polybar conf

Github notification polybar widget This tool is meant to be used with Polybar, in order to let the user know when they have notifications on Github. R

Jan 26, 2022
May 11, 2023
Automating Kubernetes Rollouts with Argo and Prometheus. Checkout the demo URL below
Automating Kubernetes Rollouts with Argo and Prometheus. Checkout the demo URL below

observe-argo-rollout Demo for Automating and Monitoring Kubernetes Rollouts with Argo and Prometheus Performing Demo The demo can be found on Katacoda

Nov 16, 2022
A plugin for argo which behaves like I'd like

argocd-lovely-plugin An ArgoCD plugin to perform various manipulations in a sensible order to ultimately output YAML for Argo CD to put into your clus

Dec 27, 2022
Simple example using Git actions + Argo CD + K8S + Docker and GO lang

CICD-simple_example Simple example using Git actions + Argo CD + K8S + Docker and GO lang Intro Pre reqs Have an ArgoCD account and Installed. Docker

Oct 28, 2021
Argo CD ApplicationSet Controller

The ApplicationSet controller manages multiple Argo CD Applications as a single ApplicationSet unit, supporting deployments to large numbers of clusters, deployments of large monorepos, and enabling secure Application self-service.

Dec 14, 2022
Automatic container image update for Argo CD

Argo CD Image Updater Introduction Argo CD Image Updater is a tool to automatically update the container images of Kubernetes workloads which are mana

Dec 25, 2022
A Kubernetes operator for managing Argo CD clusters.

Argo CD Operator A Kubernetes operator for managing Argo CD clusters. Documentation See the documentation for installation and usage of the operator.

Dec 14, 2022
Support for extending Argo CD

Argo CD Extensions To enable Extensions for your Argo CD cluster will require just a single kubectl apply. Here we provide a way to extend Argo CD suc

Dec 20, 2022
Argo-CD Autopilot
Argo-CD Autopilot

Introduction New users to GitOps and Argo CD are not often sure how they should structure their repos, add applications, promote apps across environme

Jan 6, 2023
Hera is a Python framework for constructing and submitting Argo Workflows.

Hera is an Argo Workflows Python SDK. Hera aims to make workflow construction and submission easy and accessible to everyone! Hera abstracts away workflow setup details while still maintaining a consistent vocabulary with Argo Workflows.

Dec 31, 2022