Learn GitOps with ArgoCD - Ecosystem Integration

#Introduction

In episode 29 infrastructure also joined the Git flow. But GitOps doesn't live in a vacuum — in almost every organization, ArgoCD coexists with existing CI tools: a ten-year-old Jenkins, a freshly installed GitHub Actions, Tekton inside the cluster, or GitLab overseeing everything. The classic question: how do the build tool and the deploy tool communicate without blurring responsibilities?

This episode answers it with the one principle we've held since episode 18: CI builds and tests; CD (GitOps) applies from Git. All integrations in this episode are just variants of that principle — CI writes results to Git, ArgoCD reads Git. Let's see how each popular tool does this.

#Tekton

Tekton is Kubernetes-native CI/CD based on CRDs: Pipeline, Task, and PipelineRun. The cleanest integration is: Tekton builds the image, updates the manifest in the Git repo, then ArgoCD detects it and syncs.

#Pipelines and Triggers

The Tekton pipeline handles the build side:

Tekton pipeline - build then update manifest

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: build-and-update
spec:
  tasks:
    - name: build
      taskRef:
        name: buildah
    - name: update-manifest
      runAfter: [build]
      taskRef:
        name: git-update-manifest

#Triggering Sync

There are two patterns for triggering ArgoCD from Tekton:

• Passive — Tekton commits to the manifest repo; the ArgoCD registered on that repo (via webhook or polling) syncs itself. This is the most GitOps-pure: Tekton never touches ArgoCD.
• Active — after the commit, Tekton calls argocd app sync through a custom task. Faster, but gives CI deploy power — use it only if you want execution control in CI.

#Pipeline Results into Git

The way Tekton communicates build results to Git is through results. The build stores the image digest into results, the next task reads it and updates deployment.yaml in the manifest repo. A digest (not a tag) preserves reproducibility — this is what we learned in episode 16 with Image Updater.

#Jenkins

#Jenkins X: GitOps Born

Jenkins X was designed with GitOps at its core: each environment has its own manifest repo, and promotion is a PR to the environment repo. Its integration with ArgoCD is simple: ArgoCD reads the environment repo and syncs. If you already use Jenkins X, ArgoCD integration is almost effortless — just register the environment repo as an Application.

#Traditional Jenkins + ArgoCD

For classic Jenkins, the recommended pattern: Jenkins only builds, and doesn't deploy directly. Instead, Jenkins:

1. Builds the image + pushes to the registry.
2. Updates the manifest in the Git repo (using a deploy-bot credential, or prompting Image Updater to detect it — episode 16).
3. Commits and pushes.

Jenkins pipeline - only updates Git

stage('update manifests') {
  sh 'kustomize edit set image api=registry.example.com/api:${BUILD_TAG}'
  sh 'git add . && git commit -m "release api: ${BUILD_TAG}"'
  sh 'git push origin main'
}

#Webhook Triggers

So sync doesn't wait for polling, configure a webhook from the Git repo to ArgoCD. For GitHub/GitLab this is done in the ArgoCD UI (Settings → Repositories → webhook); ArgoCD provides an endpoint that receives events and immediately schedules refresh + sync. With webhooks, manifest changes reach the cluster within seconds.

#GitHub Actions

GitHub Actions is the most popular choice for repos living on GitHub. The standard pattern:

The manifest update workflow uses a deploy-bot token with write permission to the manifest repo:

- name: Update manifests
  run: |
    cd deploy
    kustomize edit set image api=${{ inputs.image }}
    git add .
    git commit -m "chore: bump api to ${{ inputs.tag }}"
    git push
  env:
    GITHUB_TOKEN: ${{ secrets.MANIFEST_REPO_TOKEN }}

#PR Automation and Status Checks

Two patterns make GitHub Actions stand out: PR automation (a bot opens a PR updating the manifest, reviewed before merge — full control for production) and status checks (an action waits for ArgoCD to mark the application Healthy before the pipeline reports success). ArgoCD also has GitHub Checks integration through argocd-notifications (episode 17), so deployment status appears right on the PR page.

#GitLab CI/CD

GitLab offers a more integrated approach.

#Auto DevOps

Auto DevOps deploys with a built-in push model — but to use ArgoCD, you disable GitLab's built-in deployment and replace it with a step that updates the manifest repo (exactly the Jenkins pattern). The GitLab environment stays on the GitLab side to track deployments, while the real execution is in ArgoCD.

#GitLab + ArgoCD

GitLab provides repository mirroring and deploy tokens that are convenient for ArgoCD. What you need to do: create a separate manifest project, set up a .gitlab-ci.yml CI to update the manifest after the build, register the repo in ArgoCD, and install a webhook (GitLab → ArgoCD). Environment management in GitLab (the environment: keyword) gives a deployment view without disturbing the GitOps model.

#Other Tools in the Ecosystem

#Migration from FluxCD

If you're coming from Flux: ArgoCD and Flux are both pull-based. The main conceptual difference: Flux uses Kustomization objects and Git's eventual consistency version; ArgoCD uses Application with a more explicit status (Sync + Health). Gradual migration: register the same repo in ArgoCD, create an Application for the same Kustomization, freeze Flux, then remove Flux. Same Git = zero manifest changes.

#Terraform Integration

As discussed in episode 29: Terraform for non-Kubernetes resources with a pipeline, Crossplane for resources that need continuous reconciliation. A common ArgoCD-Terraform integration: ArgoCD manages an operator/controller that runs Terraform (e.g. via a pipeline hook in episode 13) for cases where state must be preserved.

#Policy Engines (OPA, Kyverno)

A policy engine is the security gate between Git and the cluster (episode 28). Kyverno validates manifests when ArgoCD applies them in the cluster. OPA/Gatekeeper works similarly through ConstraintTemplate. Both ensure: no latest images, no containers running as root, all resources have limits. Because ArgoCD keeps trying to sync, manifests that violate policy keep getting rejected — and will show up as clear errors in the UI.

#Backstage Service Catalog

Backstage (Spotify) acts as the service catalog and Internal Developer Portal — the bridge between "what a team owns" and "how it's deployed". Its integration with ArgoCD goes through the @backstage/plugin-argocd plugin: developers see ArgoCD application status right from the Backstage catalog page. This is the first step toward the Internal Developer Platform we'll discuss in episode 35.

#Closing

This episode connected ArgoCD with its ecosystem: Tekton with pipelines and Git-native triggers, Jenkins and Jenkins X with the "CI never deploys directly" pattern, GitHub Actions with manifest update workflows and status checks, GitLab with Auto DevOps and environment management, plus other supporting tools: FluxCD migration, Terraform integration, policy engines, and the Backstage catalog.

The points you should take with you:

• Every integration follows one principle: CI writes to Git, ArgoCD reads Git.
• Webhooks speed up detection; polling remains the safety net.
• Jenkins/CI never deploys directly to the cluster.
• ArgoCD can manage resources created by Tekton, Crossplane, or CAPI.
• Backstage connects the service catalog with deployment status.

The ecosystem is connected; now you need to adapt the patterns to the cloud you run on. In the next episode 31 we discuss cloud provider specific patterns — AWS EKS, GCP GKE, Azure AKS, and multi-cloud patterns with cloud-agnostic abstractions. See you in episode 31!