Skip to main content

Check out Port for yourself 

ArgoCD

Port's ArgoCD integration allows you to model ArgoCD resources in your software catalog and ingest data into them.

Overview​

This integration allows you to:

  • Map and organize your desired ArgoCD resources and their metadata in Port (see supported resources below).
  • Watch for ArgoCD object changes (create/update/delete) in real-time, and automatically apply the changes to your software catalog.

Supported resources​

The resources that can be ingested from ArgoCD into Port are listed below. It is possible to reference any field that appears in the API responses linked below in the mapping configuration.

Prerequisites​

Generate an ArgoCD token​

  1. Navigate to <serverURL>/settings/accounts/<user>. For example, if you access your ArgoCD at https://localhost:8080, you should navigate to https://localhost:8080/settings/accounts/<user>

  2. The user should have apiKey capabilities to allow generating authentication tokens for API access. If you don't have a user created yet, follow the guide on how to create a new ArgoCD user

  3. Newly created users may have limited scope to resources by default. For that reason, You will need to configure the RBAC policy for the new user by following this guide

  4. Ensure that the policy definition grants enough permission to read resources such as applications, clusters, projects, repositories etc.

  5. Under Tokens on your ArgoCD UI, Click Generate New to create a new token for the user or use the CLI:

    argocd account generate-token --account <username>

  6. Create an ArgoCD user with readonly permissions

    1. Create an argocd-user.yaml file with the below manifest to create a new user port-ocean-user
    Create user manifest (click to expand) 
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: argocd-cm
      namespace: argocd
      labels:
        app.kubernetes.io/name: argocd-cm
        app.kubernetes.io/part-of: argocd
    data:
      # add an additional local user with apiKey and login capabilities
      #   apiKey - allows generating API keys
      #   login - allows to login using UI
      accounts.port-ocean-user: apiKey, login
      accounts.port-ocean-user.enabled: "true"
    1. Apply the manifest with kubectl to create the user:
    kubectl apply -f argocd-user.yaml
    1. Grant read only RBAC policy to the new user using the below manifest file (argocd-rbac-cm.yaml)
    RBAC policy to grant readonly role to the new user (click to expand) 
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: argocd-rbac-cm
      namespace: argocd
    data:
      policy.default: role:readonly
      policy.csv: |
        p, role:read-only-role, applications, *, */*, allow
        p, role:read-only-role, clusters, get, *, allow
        p, role:read-only-role, repositories, get, *, allow
        p, role:read-only-role, projects, get, *, allow
        p, role:read-only-role, logs, get, *, allow

        g, port-ocean-user, role:read-only-role
    1. Apply the argocd-rbac-cm.yaml manifest with kubectl:
    kubectl apply -f argocd-rbac-cm.yaml
    1. Go to your ArgoCD UI to generate a new token for the user or use the CLI
    argocd account generate-token --account <username>

Setup​

Choose one of the following installation methods:
Not sure which method is right for your use case? Check the available installation methods.

Loading version...

Using this installation method means that the integration will be able to update Port in real time using webhooks.

Prerequisites

To install the integration, you need a Kubernetes cluster that the integration's container chart will be deployed to.

Please make sure that you have kubectl and helm installed on your machine, and that your kubectl CLI is connected to the Kubernetes cluster where you plan to install the integration.

Troubleshooting

If you are having trouble installing this integration, please refer to these troubleshooting steps.

For details about the available parameters for the installation, see the table below.

To install the integration using Helm:

  1. Go to the Argocd data source page in your portal.

  2. Select the Real-time and always on method:

  3. A helm command will be displayed, with default values already filled out (e.g. your Port client ID, client secret, etc).
    Copy the command, replace the placeholders with your values, then run it in your terminal to install the integration.

BaseUrl & webhook configuration

AppHost deprecation

integration.config.appHost is deprecated: Please use liveEvents.baseUrl for webhook URL settings instead.

In order for the Argocd integration to update the data in Port on real-time changes in Argocd, you need to specify the liveEvents.baseUrl parameter. The liveEvents.baseUrl parameter should be set to the url of your Argocd integration instance. Your integration instance needs to have the option to setup webhooks via http requests/recieve http requests , so please configure your network accordingly.

Debugging local integrations

To test webhooks or live event delivery to your local environment, expose your local pod or service to the internet using ngrok:

ngrok http http://localhost:8000

This will provide a public URL you can use for webhook configuration and external callbacks during development.

If liveEvents.baseUrl is not provided, the integration will continue to function correctly. In such a configuration, to retrieve the latest information from the target system, the scheduledResyncInterval parameter has to be set, or a manual resync will need to be triggered through Port's UI.

Scalable Mode for Large Integrations

If you are deploying the integration at scale and want to decouple the resync process from the live events process (recommended for large or high-throughput environments), you can enable scalable mode by adding the following flags to your Helm install command:

  --set workload.kind="CronJob"  \
  --set workload.cron.resyncTimeoutMinutes=60  \
  --set scheduledResyncInterval="'*/60 * * * *'"  \
  --set liveEvents.worker.enabled=true
Selecting a Port API URL by account region

The port_region, port.baseUrl, portBaseUrl, port_base_url and OCEAN__PORT__BASE_URL parameters are used to select which instance of Port API will be used.

Port exposes two API instances, one for the EU region of Port, and one for the US region of Port.

This table summarizes the available parameters for the installation. Note the parameters specific to this integration, they are last in the table.

ParameterDescriptionRequired
port.clientIdYour port client id✅
port.clientSecretYour port client secret✅
port.baseUrlYour Port API URL - https://api.getport.io for EU, https://api.us.getport.io for US✅
initializePortResourcesDefault true, When set to true the integration will create default blueprints and the port App config Mapping❌
sendRawDataExamplesEnable sending raw data examples from the third party API to port for testing and managing the integration mapping. Default is true❌
integration.identifierChange the identifier to describe your integration✅
integration.typeThe integration type✅
integration.eventListener.typeThe event listener type✅
integration.secrets.tokenThe ArgoCD API token, docs can be found here✅
integration.config.serverUrlThe ArgoCD server url✅
integration.config.ignoreServerErrorWhether to ignore server errors when fetching data from ArgoCD. The default value is false meaning the integration will raise exceptions and fail the resync event❌
scheduledResyncIntervalThe number of minutes between each resync❌

Configuration​

Port integrations use a YAML mapping block to ingest data from the third-party api into Port.

The mapping makes use of the JQ JSON processor to select, modify, concatenate, transform and perform other operations on existing fields and values from the integration API.

Default mapping configuration​

This is the default mapping configuration for this integration:

Default mapping configuration (Click to expand)
deleteDependentEntities: true
createMissingRelatedEntities: true
enableMergeEntity: true
resources:
- kind: cluster
  selector:
    query: 'true'
  port:
    entity:
      mappings:
        identifier: .name
        title: .name
        blueprint: '"argocdCluster"'
        properties:
          applicationsCount: .info.applicationsCount
          serverVersion: .serverVersion
          labels: .labels
          updatedAt: .connectionState.attemptedAt
          server: .server
- kind: cluster
  selector:
    query: 'true'
  port:
    entity:
      mappings:
        identifier: .name + "-" + .item | tostring
        title: .name + "-" + .item
        blueprint: '"argocdNamespace"'
        relations:
          cluster: .name
    itemsToParse: .namespaces
- kind: project
  selector:
    query: 'true'
  port:
    entity:
      mappings:
        identifier: .metadata.name
        title: .metadata.name
        blueprint: '"argocdProject"'
        properties:
          createdAt: .metadata.creationTimestamp
          description: .spec.description
- kind: application
  selector:
    query: 'true'
  port:
    entity:
      mappings:
        identifier: .metadata.uid
        title: .metadata.name
        blueprint: '"argocdApplication"'
        properties:
          gitRepo: .spec.source.repoURL
          gitPath: .spec.source.path
          destinationServer: .spec.destination.server
          revision: .status.sync.revision
          targetRevision: .spec.source.targetRevision
          syncStatus: .status.sync.status
          healthStatus: .status.health.status
          createdAt: .metadata.creationTimestamp
          labels: .metadata.labels
          annotations: .metadata.annotations
        relations:
          project: .spec.project
          namespace: .metadata.namespace
          environment:
            combinator: '"and"'
            rules:
            - operator: '"="'
              property: '"argoCluster"'
              value: .spec.destination.server
          cluster:
            combinator: '"and"'
            rules:
            - operator: '"="'
              property: '"server"'
              value: .spec.destination.server
- kind: application
  selector:
    query: 'true'
  port:
    entity:
      mappings:
        identifier: .metadata.uid + "-" + (.item.id | tostring)
        title: .metadata.name + "-" + (.item.id | tostring)
        blueprint: '"argocdDeploymentHistory"'
        properties:
          deployedAt: .item.deployedAt
          deployStartedAt: .item.deployStartedAt
          revision: .item.source.repoURL + "/commit/" + .item.revision
          initiatedBy: .item.initiatedBy.username
          repoURL: .item.source.repoURL
          sourcePath: .item.source.path
        relations:
          application: .metadata.uid
          anotherRelation: .item.source.repoURL
    itemsToParse: .status.history // []

Capabilities​

Configure real-time updates​

Currently, the ArgoCD REST API lacks support for programmatic webhook creation. To set up a webhook configuration in ArgoCD for sending notifications to the Ocean integration, follow these steps:

  1. Install ArgoCD notifications manifest;
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj-labs/argocd-notifications/release-1.0/manifests/install.yaml
  1. Install ArgoCD triggers and templates manifest;
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj-labs/argocd-notifications/release-1.0/catalog/install.yaml
  1. Use kubectl to connect to the Kubernetes cluster where your ArgoCD instance is deployed;
kubectl config use-context <your-cluster-context>
  1. Set the current namespace to your ArgoCD namespace, use the following command;
kubectl config set-context --current --namespace=<your-namespace>

  1. Create a YAML file (e.g. argocd-webhook-config.yaml) that configures the webhook notification service. The example below shows how to set up a webhook to send real-time events whenever ArgoCD applications are updated. The YAML file includes the following components:

    1. Notification service definition;
    2. Template for the webhook message body;
    3. Trigger definitions;
    4. Subscriptions to the notifications.

    Here's an example YAML. Make sure to replace <WEBHOOK_URL> with the actual URL of the ingress or service where the ocean integration will be deployed. By default, incoming webhook events are sent to /integration/webhook path in Ocean so do not replace the path parameter.

    webhook manifest file 
    apiVersion: v1
    kind: ConfigMap
    metadata:
    name: argocd-notifications-cm
    data:
    trigger.on-sync-operation-change: |
      - description: Application syncing has updated
      send:
      - app-status-change
      when: app.status.operationState.phase in ['Error', 'Failed', 'Succeeded', 'Running']
    trigger.on-deployed: |
      - description: Application is synced and healthy
      send:
      - app-status-change
      when: app.status.operationState.phase in ['Succeeded'] and app.status.health.status == 'Healthy'
    trigger.on-health-degraded: |
      - description: Application has degraded
      send:
      - app-status-change
      when: app.status.health.status == 'Degraded'
    service.webhook.port-ocean: |
      url: <WEBHOOK_URL>
      headers:
      - name: Content-Type
      value: application/json
    template.app-status-change: |
      webhook:
      port-ocean:
          method: POST
          path: /integration/webhook
          body: |
          {
              "action": "upsert",
              "application_name": "{{.app.metadata.name}}"
          }
    subscriptions: |
      - recipients:
      - port-ocean
      triggers:
      - on-deployed
      - on-health-degraded
      - on-sync-operation-change

  2. Use kubectl to apply the YAML file to your cluster. Run the following command, replacing <your-namespace> with your ArgoCD namespace and <path-to-yaml-file> with the actual path to your YAML file:

kubectl apply -n <your-namespace> -f <path-to-yaml-file>

This command deploys the webhook notification configuration to your ArgoCD notification configmap (argocd-notifications-cm), allowing Ocean to receive real-time events.

Monitoring and sync status​

To learn more about how to monitor and check the sync status of your integration, see the relevant documentation.

Examples​

To view and test the integration's mapping against examples of the third-party API responses, use the jq playground in your data sources page. Find the integration in the list of data sources and click on it to open the playground.

Examples of blueprints and the relevant integration configurations can be found on the argocd examples page

Relevant Guides​

For relevant guides and examples, see the guides section.

Alternative installation via webhook​

While the Ocean integration described above is the recommended installation method, you may prefer to use a webhook to ingest data from ArgoCD. If so, use the following instructions:

Webhook installation (click to expand)

In this example you are going to create a webhook integration between ArgoCD and Port, which will ingest application entities and map them to your ArgoCD projects.

Port configuration

Create the following blueprint definition:

Project blueprint
{
  "identifier": "argocdProject",
  "description": "This blueprint represents an ArgoCD Project",
  "title": "ArgoCD Project",
  "icon": "Argo",
  "schema": {
    "properties": {
      "description": {
        "title": "Description",
        "description": "Project description",
        "type": "string",
        "icon": "DefaultProperty"
      }
    },
    "required": []
  },
  "mirrorProperties": {},
  "calculationProperties": {},
  "relations": {}
}
Application blueprint
{
  "identifier": "argocdApplication",
  "description": "This blueprint represents an ArgoCD Application",
  "title": "ArgoCD Application",
  "icon": "Argo",
  "schema": {
    "properties": {
      "gitRepo": {
        "type": "string",
        "format": "url",
        "icon": "Git",
        "title": "Repository URL",
        "description": "The URL of the Git repository containing the application source code"
      },
      "gitPath": {
        "type": "string",
        "title": "Path",
        "description": "The path within the Git repository where the application manifests are located"
      },
      "destinationServer": {
        "type": "string",
        "title": "Destination Server",
        "format": "url"
      },
      "namespace": {
        "type": "string",
        "title": "Namespace"
      },
      "syncStatus": {
        "type": "string",
        "title": "Sync Status",
        "enum": ["Synced", "OutOfSync", "Unknown"],
        "enumColors": {
          "Synced": "green",
          "OutOfSync": "red",
          "Unknown": "lightGray"
        },
        "description": "The sync status of the application"
      },
      "healthStatus": {
        "type": "string",
        "title": "Health Status",
        "enum": [
          "Healthy",
          "Missing",
          "Suspended",
          "Degraded",
          "Progressing",
          "Unknown"
        ],
        "enumColors": {
          "Healthy": "green",
          "Missing": "yellow",
          "Suspended": "purple",
          "Degraded": "red",
          "Progressing": "blue",
          "Unknown": "lightGray"
        },
        "description": "The health status of the application"
      },
      "createdAt": {
        "title": "Created At",
        "type": "string",
        "format": "date-time"
      }
    },
    "required": []
  },
  "mirrorProperties": {},
  "calculationProperties": {},
  "relations": {
    "project": {
      "title": "Project",
      "target": "argocdProject",
      "required": false,
      "many": false
    }
  }
}

Create the following webhook configuration using Port UI

Application webhook configuration

  1. Basic details tab - fill the following details:

    1. Title : ArgoCD Application Mapper;
    2. Identifier : argocd_application_mapper;
    3. Description : A webhook configuration to map ArgoCD applications to Port;
    4. Icon : Argo;

  2. Integration configuration tab - fill the following JQ mapping:

    [
      {
        "blueprint": "argocdApplication",
        "filter": "true",
        "entity": {
          "identifier": ".body.uid | tostring",
          "title": ".body.name | tostring",
          "properties": {
            "gitRepo": ".body.git_repo",
            "gitPath": ".body.git_path",
            "destinationServer": ".body.destination_server",
            "namespace": ".body.namespace",
            "syncStatus": ".body.sync_status",
            "healthStatus": ".body.health_status",
            "createdAt": ".body.created_at"
          },
          "relations": {
            "project": ".body.project"
          }
        }
      }
    ]

  3. Click Save at the bottom of the page.

Create a webhook in ArgoCD

To set up a webhook configuration in ArgoCD for sending notifications to Port, follow these steps:

Prerequisite

  1. You have access to a Kubernetes cluster where ArgoCD is deployed.
  2. You have kubectl installed and configured to access your cluster.

Steps

  1. Install ArgoCD notifications manifest;
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj-labs/argocd-notifications/release-1.0/manifests/install.yaml
  1. Install ArgoCD triggers and templates manifest;
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj-labs/argocd-notifications/release-1.0/catalog/install.yaml
  1. Use kubectl to connect to the Kubernetes cluster where your ArgoCD instance is deployed;
kubectl config use-context <your-cluster-context>
  1. Set the current namespace to your ArgoCD namespace, use the following command;
kubectl config set-context --current --namespace=<your-namespace>

  1. Create a YAML file (e.g. argocd-webhook-config.yaml) that configures the webhook notification service. The example below shows how to set up a webhook to send real-time events whenever ArgoCD applications are updated. The YAML file includes the following components:

    1. Notification service definition;
    2. Template for the webhook message body;
    3. Trigger definitions;
    4. Subscriptions to the notifications.

    Here's an example YAML. Make sure to replace <YOUR_WEBHOOK_URL> with the value of url key you received after creating the webhook configuration.

    webhook manifest file 
    apiVersion: v1
    kind: ConfigMap
    metadata:
    name: argocd-notifications-cm
    data:
    trigger.on-sync-operation-change: |
      - description: Application syncing has updated
      send:
      - app-status-change
      when: app.status.operationState.phase in ['Error', 'Failed', 'Succeeded', 'Running']
    trigger.on-deployed: |
      - description: Application is synced and healthy
      send:
      - app-status-change
      when: app.status.operationState.phase in ['Succeeded'] and app.status.health.status == 'Healthy'
    trigger.on-health-degraded: |
      - description: Application has degraded
      send:
      - app-status-change
      when: app.status.health.status == 'Degraded'
    service.webhook.port-webhook: |
      url: <YOUR_WEBHOOK_URL>
      headers:
      - name: Content-Type
      value: application/json
    template.app-status-change: |
      webhook:
      port-webhook:
          method: POST
          body: |
          {
              "uid": "{{.app.metadata.uid}}",
              "name": "{{.app.metadata.name}}",
              "namespace": "{{.app.metadata.namespace}}",
              "sync_status": "{{.app.status.sync.status}}",
              "health_status": "{{.app.status.health.status}}",
              "git_repo": "{{.app.spec.source.repoURL}}",
              "git_path": "{{.app.spec.source.path}}",
              "destination_server": "{{.app.spec.destination.server}}",
              "created_at": "{{.app.metadata.creationTimestamp}}",
              "project": "{{.app.spec.project}}"
          }
    subscriptions: |
      - recipients:
      - port-webhook
      triggers:
      - on-deployed
      - on-health-degraded
      - on-sync-operation-change

  2. Use kubectl to apply the YAML file to your cluster. Run the following command, replacing <your-namespace> with your ArgoCD namespace and <path-to-yaml-file> with the actual path to your YAML file:

kubectl apply -n <your-namespace> -f <path-to-yaml-file>

This command deploys the webhook notification configuration to your ArgoCD notification configmap (argocd-notifications-cm), allowing Port to receive real-time events.

Done! any change that happens to your applications in ArgoCD will trigger a webhook event to the webhook URL provided by Port. Port will parse the events according to the mapping and update the catalog entities accordingly.

Argocd Events

In this example you are going to create a webhook integration between ArgoCD and Port, which will ingest all events entities and map them to your ArgoCD applications.

Port configuration

Create the following blueprint definition:

Events blueprint
{
  "identifier": "argocdEvent",
  "description": "This blueprint represents ArgoCD events",
  "title": "ArgoCD Events",
  "icon": "Argo",
  "schema": {
    "properties": {
      "event": {
        "type": "string",
        "title": "Event Name"
      },
      "namespace": {
        "type": "string",
        "title": "Namespace"
      },
      "description": {
        "type": "string",
        "title": "Description"
      }
    },
    "required": []
  },
  "mirrorProperties": {},
  "calculationProperties": {},
  "aggregationProperties": {},
  "relations": {
    "application": {
      "title": "Application",
      "target": "argocdApplication",
      "required": false,
      "many": false
    }
  }
}

Create the following webhook configuration using Port UI

Application webhook configuration

  1. Basic details tab - fill the following details:

    1. Title : ArgoCD Event Mapper;
    2. Identifier : argocd_event_mapper;
    3. Description : A webhook configuration to map ArgoCD events to Port;
    4. Icon : Argo;

  2. Integration configuration tab - fill the following JQ mapping:

    [
      {
        "blueprint": "argocdEvent",
        "filter": "true",
        "entity": {
          "identifier": ".body.app_name + \"-\" + .body.event_name | tostring",
          "title": ".body.event_name | tostring",
          "properties": {
            "event": ".body.event_name",
            "namespace": ".body.namespace",
            "description": ".body.description"
          },
          "relations": {
            "application": ".body.uid"
          }
        }
      }
    ]

  3. Click Save at the bottom of the page.

Create a webhook in ArgoCD

To set up a webhook configuration in ArgoCD for sending notifications to Port, follow these steps:

Prerequisite

  1. You have access to a Kubernetes cluster where ArgoCD is deployed.
  2. You have kubectl installed and configured to access your cluster.

Steps

  1. Install ArgoCD notifications manifest;
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj-labs/argocd-notifications/release-1.0/manifests/install.yaml
  1. Install ArgoCD triggers and templates manifest;
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj-labs/argocd-notifications/release-1.0/catalog/install.yaml
  1. Use kubectl to connect to the Kubernetes cluster where your ArgoCD instance is deployed;
kubectl config use-context <your-cluster-context>
  1. Set the current namespace to your ArgoCD namespace, use the following command;
kubectl config set-context --current --namespace=<your-namespace>

  1. Create a YAML file (e.g. argocd-events-config.yaml) that configures the webhook notification service. The example below shows how to set up a webhook to send real-time events from ArgoCD. The YAML file includes the following components:

    1. Notification service definition;
    2. Template for the webhook message body;
    3. Trigger definitions;
    4. Subscriptions to the notifications.

    Here's an example YAML. Make sure to replace <YOUR_WEBHOOK_URL> with the value of url key you received after creating the webhook configuration.

    event manifest file 
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: argocd-notifications-cm
    data:
      trigger.on-created: |
        - description: Application is created
          send:
          - app-created
          when: true
          oncePer: app.metadata.name
      trigger.on-sync-running: |
        - description: Application is being synced
          send:
          - app-sync-running
          when: app.status.operationState.phase in ['Running']
      trigger.on-sync-succeeded: |
        - description: Application syncing has succeeded
          send:
          - app-sync-succeeded
          when: app.status.operationState.phase in ['Succeeded']
      trigger.on-sync-failed: |
        - description: Application syncing has failed
          send:
          - app-sync-failed
          when: app.status.operationState.phase in ['Error', 'Failed']
      trigger.on-sync-status-unknown: |
        - description: Application status is Unknown
          send:
          - app-sync-status-unknown
          when: app.status.sync.status == 'Unknown'
      trigger.on-deployed: |
        - description: Application is synced and healthy
          send:
          - app-deployed
          when: app.status.operationState.phase in ['Succeeded'] and app.status.health.status == 'Healthy'
      trigger.on-health-degraded: |
        - description: Application has degraded
          send:
          - app-health-degraded
          when: app.status.health.status == 'Degraded'
      trigger.on-deleted: |
        - description: Application is deleted
          send:
          - app-deleted
          when: app.metadata.deletionTimestamp != nil
          oncePer: app.metadata.name
      service.webhook.port-webhook: |
        url: YOUR_WEBHOOK_URL
        headers:
        - name: Content-Type
          value: application/json
      template.app-created: |
        webhook:
          port-webhook:
            method: POST
            body: |
              {
                "uid": "{{.app.metadata.uid}}",
                "event_name": "on-created",
                "app_name": "{{.app.metadata.name}}",
                "namespace": "{{.app.metadata.namespace}}",
                "description": "Application is created"
              }
      template.app-sync-succeeded: |
        webhook:
          port-webhook:
            method: POST
            body: |
              {
                "uid": "{{.app.metadata.uid}}",
                "event_name": "on-sync-succeeded",
                "app_name": "{{.app.metadata.name}}",
                "namespace": "{{.app.metadata.namespace}}",
                "description": "Application syncing has succeeded"
              }
      template.app-sync-running: |
        webhook:
          port-webhook:
            method: POST
            body: |
              {
                "uid": "{{.app.metadata.uid}}",
                "event_name": "on-sync-running",
                "app_name": "{{.app.metadata.name}}",
                "namespace": "{{.app.metadata.namespace}}",
                "description": "Application is being synced"
              }
      template.app-sync-failed: |
        webhook:
          port-webhook:
            method: POST
            body: |
              {
                "uid": "{{.app.metadata.uid}}",
                "event_name": "on-sync-failed",
                "app_name": "{{.app.metadata.name}}",
                "namespace": "{{.app.metadata.namespace}}",
                "description": "Application syncing has failed"
              }
      template.app-health-degraded: |
        webhook:
          port-webhook:
            method: POST
            body: |
              {
                "uid": "{{.app.metadata.uid}}",
                "event_name": "on-health-degraded",
                "app_name": "{{.app.metadata.name}}",
                "namespace": "{{.app.metadata.namespace}}",
                "description": "Application has degraded"
              }
      template.app-deployed: |
        webhook:
          port-webhook:
            method: POST
            body: |
              {
                "uid": "{{.app.metadata.uid}}",
                "event_name": "on-deployed",
                "app_name": "{{.app.metadata.name}}",
                "namespace": "{{.app.metadata.namespace}}",
                "description": "Application is synced healthy"
              }
      template.app-sync-status-unknown: |
        webhook:
          port-webhook:
            method: POST
            body: |
              {
                "uid": "{{.app.metadata.uid}}",
                "event_name": "on-sync-status-unknown",
                "app_name": "{{.app.metadata.name}}",
                "namespace": "{{.app.metadata.namespace}}",
                "description": "Application status is Unknown"
              }
      template.app-deleted: |
        webhook:
          port-webhook:
            method: POST
            body: |
              {
                "uid": "{{.app.metadata.uid}}",
                "event_name": "on-deleted",
                "app_name": "{{.app.metadata.name}}",
                "namespace": "{{.app.metadata.namespace}}",
                "description": "Application  deleted"
              }
      subscriptions: |
        - recipients:
            - port-webhook
          triggers:
            - on-created
            - on-deployed
            - on-health-degraded
            - on-sync-failed
            - on-sync-status-unknown
            - on-sync-succeeded
            - on-sync-running
            - on-deleted

  2. Use kubectl to apply the YAML file to your cluster. Run the following command, replacing <your-namespace> with your ArgoCD namespace and <path-to-yaml-file> with the actual path to your YAML file:

kubectl apply -n <your-namespace> -f <path-to-yaml-file>

This command deploys the webhook notification configuration to your ArgoCD notification configmap (argocd-notifications-cm), allowing Port to receive real-time events.

Done! any change that happens to your applications in ArgoCD will trigger a webhook event to the webhook URL provided by Port. Port will parse the events according to the mapping and update the catalog entities accordingly.