Argo CD Version Tags

Open in ChatGPTOpen in Claude

Coralogix provides seamless integration with Argo CD so you can push tags to Coralogix automatically from your Argo CD pipelines.

Prerequisites

• Have Argo CD installed, for more information on how to install: https://argo-cd.readthedocs.io/en/stable/getting_started/

• Have Argo CD Notifications and Triggers and templates installed, for more information on how to install: https://argo-cd.readthedocs.io/en/stable/operator-manual/notifications/

• To use this API you need to create a personal or team API key. It’s recommended to use permission presets, as they are automatically updated with all relevant permissions. Alternatively, you can manually add individual permissions.

  Preset	Action	Description
  CICDIntegration	VERSION-BENCHMARK-TAGS:READ VERSION-BENCHMARKS-REPORTS:READ VERSION-BENCHMARK-TAGS:UPDATE	View Version Benchmark Tags View Version Benchmark Reports Modify Version Benchmark Tags

Configuration

Add the Coralogix API Key to argocd-notifications-secret Secret:

apiVersion: v1
kind: Secret
metadata:
  name: argocd-notifications-secret
type: Opaque
stringData:
  coralogix-api-token: <cx_api_key>

Add webhook, template and trigger to argocd-notifications-cm ConfigMap. Choose the https://api./api/v1/external/tags endpoint that corresponds to your Coralogix domain using the domain selector at the top of the page for the url.

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-notifications-cm
data:
  service.webhook.coralogix: |
    url: https://api.eu2.coralogix.com/api/v1/external/tags
    headers:
    - name: Authorization
      value: Bearer $coralogix-api-token
    - name: Content-Type
      value: application/json
  template.coralogix: |
    webhook:
      coralogix:
        method: POST
        body: |
          {
            "name": "{{.app.status.sync.revision}}",
            "application": ["{{.app.spec.project}}"],
            "subsystem": ["{{.app.metadata.name}}"],
            "iconUrl": "https://raw.githubusercontent.com/coralogix/integrations-docs/master/integrations/argocd/images/argocd.png"
          }
  trigger.coralogix-on-success: |
    - when: app.status.operationState.phase in ['Succeeded']
      send: [coralogix]

There are 2 ways to publish a patch with the added annotation. Either create a .yml and perform the patch by specifying the patch file or use a command with the patch written into it.

• The .yml file:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: <deployed-app-name>
  annotations:
    notifications.argoproj.io/subscribe.coralogix-on-success.coralogix: ""

• The command:

kubectl patch app <deployed-app-name> -n argocd -p '{"metadata": {"annotations": {"notifications.argoproj.io/subscribe.coralogix-on-success.coralogix": ""}}}' --type merge

In Argocd, enter the deployed app in which the notifications were added under the annotations field to check if the patch was successfully created. You will find the Coralogix notification.
Each time the application syncs in Argocd, it automatically sends a tag to the Coralogix dashboard.

Send deployment events

Send each sync to the Coralogix ops events API as well, and it appears as an event marker on your APM charts, so you can line a latency or error-rate change up with the sync that caused it. This uses the same Argo CD Notifications controller as version tags.

What you need

• A Send Your Data API key with the OpsEvents role preset. The ops events API rejects any other key type or preset, including the CICDIntegration key used for version tags, with 403 Forbidden.
• The ops events endpoint for your Coralogix domain. Use the domain selector at the top of this page to resolve it: https://api./v1/ops-events
• The service name and environment exactly as they appear in APM. They must equal the service.name and deployment.environment.name resource attributes your service reports. An event that matches no service is still stored, but appears only under All events.

Configure the notification

Add the ops events API key to argocd-notifications-secret under a key of its own:

apiVersion: v1
kind: Secret
metadata:
  name: argocd-notifications-secret
type: Opaque
stringData:
  coralogix-ops-events-token: <cx_api_key>

Add the service, template, and triggers to argocd-notifications-cm, alongside the version tag entries. Set context.argocdUrl to your Argo CD URL so each event links back to the application.

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-notifications-cm
data:
  context: |
    argocdUrl: https://argocd.example.com
  service.webhook.coralogix-ops-events: |
    url: https://api.eu2.coralogix.com/v1/ops-events
    headers:
    - name: Authorization
      value: Bearer $coralogix-ops-events-token
    - name: Content-Type
      value: application/json
  template.coralogix-deployment-event: |
    webhook:
      coralogix-ops-events:
        method: POST
        body: |
          {{- $annotations := default dict .app.metadata.annotations -}}
          {
            "opsEvent": {
              "timestamp": "{{.app.status.operationState.finishedAt}}",
              "description": "{{.app.metadata.name}} synced to {{.app.status.operationState.syncResult.revision}}",
              "attributes": {
                "service": { "name": "{{index $annotations "coralogix.com/apm-service" | default .app.metadata.name}}" },
                "environment": "{{index $annotations "coralogix.com/environment" | default .app.spec.destination.namespace}}"
              },
              "cdEvent": {
                "system": "CD_SYSTEM_ARGOCD",
                "pipeline": {
                  "name": "{{.app.metadata.name}}",
                  "run": {
                    "id": "{{.app.status.operationState.syncResult.revision}}",
                    "url": "{{.context.argocdUrl}}/applications/{{.app.metadata.name}}"
                  },
                  "result": { "status": "{{if eq .app.status.operationState.phase "Succeeded"}}PIPELINE_RESULT_STATUS_SUCCESS{{else}}PIPELINE_RESULT_STATUS_FAILURE{{end}}" },
                  "task": { "name": "sync", "type": "PIPELINE_TASK_TYPE_DEPLOY" }
                },
                "vcs": {
                  "system": "VCS_SYSTEM_GITHUB",
                  "type": "VCS_REF_TYPE_BRANCH",
                  "repository": {
                    "name": "{{call .repo.FullNameByRepoURL .app.spec.source.repoURL}}",
                    "url": "{{call .repo.RepoURLToHTTPS .app.spec.source.repoURL}}"
                  },
                  "ref": {
                    "head": {
                      "name": "{{.app.spec.source.targetRevision}}",
                      "revision": "{{.app.status.operationState.syncResult.revision}}"
                    }
                  }
                }
              }
            }
          }
  trigger.coralogix-on-deployed: |
    - when: app.status.operationState.phase in ['Succeeded'] and app.status.health.status == 'Healthy'
      oncePer: app.status.operationState.syncResult.revision
      send: [coralogix-deployment-event]
  trigger.coralogix-on-sync-failed: |
    - when: app.status.operationState.phase in ['Error', 'Failed']
      oncePer: app.status.operationState.syncResult.revision
      send: [coralogix-deployment-event]

Adjust the template to your setup:

• Set vcs.system to VCS_SYSTEM_GITLAB or VCS_SYSTEM_BITBUCKET if your manifests live there, and vcs.type to VCS_REF_TYPE_TAG if you deploy from tags.
• Keep oncePer on both triggers. It sends one event per synced revision; without it, a sync that completes between two reconciles can be missed.
• The template reads .app.spec.source, so it fails to render for multi-source applications that use spec.sources. Argo CD logs the failure and does not retry that event.

Subscribe your applications

Subscribe each application to the triggers, and set the service name and environment APM shows for it. Without the annotations, the template falls back to the application name and destination namespace, which match APM only when your naming already lines up.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: <deployed-app-name>
  annotations:
    notifications.argoproj.io/subscribe.coralogix-on-deployed.coralogix-ops-events: ""
    notifications.argoproj.io/subscribe.coralogix-on-sync-failed.coralogix-ops-events: ""
    coralogix.com/apm-service: <service_name>
    coralogix.com/environment: <environment>

A successful request returns the server-generated event id. The marker then appears on the service's APM charts; see Event markers for how to show it and for the full field reference. The API rejects a timestamp more than 24 hours from the time the request is received, so send the event from the pipeline as it runs rather than backfilling. If no marker appears, check the argocd-notifications-controller logs for the delivery result.

Additional resources

Coralogix Endpoints	Coralogix Endpoints