Learn GitOps with ArgoCD - CI/CD Pipeline Integration

#Introduction

In episode 17 we discussed notifications & alerts — how ArgoCD informs the team via Slack, email, or webhook when sync or health status changes. But up to this point we've treated Git as a source that "suddenly changes" without understanding who changes it. In this episode we close that loop: integrating ArgoCD with CI/CD pipelines, so that from code commit to a live application in the cluster is one traceable flow.

Why does this matter? In traditional setups, CI and CD are often merged: one pipeline runs the build then immediately does kubectl apply to the cluster. The problem is that pipeline holds cluster credentials, and every deployment is a decision recorded only in pipeline logs that can disappear. GitOps offers a healthier division of labor: CI is responsible for building and testing artifacts, while CD — held by ArgoCD — is responsible for applying the approved configuration in Git. CI may hold registry credentials; CD only needs to read Git. After this episode, you'll understand this pattern down to the implementation level.

#Understanding the CI and CD Separation

Before writing a pipeline, you must understand who does what. The GitOps model splits the flow into two domains with different interests:

In essence: CI produces artifacts, CD applies artifacts. ArgoCD doesn't need to know how the image was built; it only needs to know that the image with a certain tag exists in the registry, then materializes it in the cluster. This separation lets CI be re-run without affecting the cluster, and makes CD rollback independent of the pipeline.

#Building a CI Pipeline: The Build Stage

The build stage is the sequence of steps that produces an image. The industry standard uses five sequential steps:

1. Code checkout — fetches the source code from a specific branch/commit.
2. Build and test — install dependencies, lint, unit test, build artifacts. Failing here means the flow stops before wasting time on the next step.
3. Build the container image — from the tested artifacts, an image is built with a unique tag.
4. Push to the registry — the image is sent to a registry (ECR, GCR, GHCR, Docker Hub).
5. Security scanning — the image is scanned for CVEs before being allowed into the cluster.

name: ci
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: bun install --frozen-lockfile
      - run: bun run lint && bun run test
      - uses: docker/setup-buildx-action@v3
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v6
        with:
          push: true
          tags: ghcr.io/org/api:${{ github.sha }}

      - uses: aquasecurity/trivy-action@master
        with:
          image-ref: ghcr.io/org/api:${{ github.sha }}
          severity: CRITICAL,HIGH
          exit-code: "1"

Notice the image tag pattern: using the commit SHA as the tag is the cheapest way to create immutable artifacts — every commit produces an image that is never overwritten, so you can always reconstruct the exact version running in production. Trivy's exit-code: "1" makes the pipeline fail if high-severity CVEs are found — this is the security gate before an image enters the cluster.

#Connecting CI to CD: Updating Manifests in Git

After the image is in the registry, CI's job isn't done. In the GitOps model, the next step is updating the manifests in Git so ArgoCD sees the new image. The easiest option is Kustomize images (from episode 8):

      - uses: azure/setup-kubectl@v4
      - uses: imranismail/setup-kustomize@v2
      - run: |
          cd manifests/overlays/staging
          kustomize edit set image ghcr.io/org/api:${{ github.sha }}
          git config user.name "ci-bot"
          git config user.email "ci@org.dev"
          git commit -am "chore(staging): bump api to ${{ github.sha }}"
          git push

After the git push, two things can happen depending on the Application's syncPolicy:

If the Application uses automated sync, there's no more manual step — ArgoCD sees the Git change, syncs, and the health check runs. If manual, the team runs:

Manual sync after approval

argocd app get api --show-operation
argocd app sync api --strategy apply
argocd app wait api --health

#Implementation Examples on Other CI Platforms

The same pattern — build, push, update manifest, ArgoCD sync — can be built on any platform. Only the syntax differs:

The key to remember: never call argocd app sync from a pipeline to "deploy". ArgoCD should pull from Git by itself. If you call sync from the pipeline, you're back to the push model, and GitOps's main claim — all changes originate from Git — breaks. Let ArgoCD be the driver.

#Best Practices

1. Separate CI and CD for real. The CI pipeline only produces artifacts; deployment is ArgoCD's job. Don't build one giant pipeline that does both.
2. Use immutable artifacts. Tag images with a commit SHA or a semver that is never overwritten. The latest tag is the enemy of reproducibility.
3. Use promotion pipelines. The dev → staging → prod flow is realized by promoting the same tag (not rebuilding). The image tested in staging must be exactly the one used in prod.
4. Automate rollback. Because every version is a commit in Git, rollback is just git revert or argocd app rollback. Document the rollback steps in a runbook.
5. Keep feedback fast. Fail the pipeline as early as possible: lint before build, build before scan, scan before push.

#Testing Strategies

A good deployment is tested before and after being applied:

• Pre-deployment validation — run it in the CI stage: unit tests, integration tests against the built image, and manifest linting (kubectl kustomize or helm template --validate) to catch broken YAML before it enters Git.
• Post-deployment smoke tests — run via a PostSync hook (from episode 13). ArgoCD only marks the sync successful after the hook finishes, so a failing smoke test automatically blocks the application status:

PostSync hook smoke test

apiVersion: batch/v1
kind: Job
metadata:
  name: api-smoke-test
  annotations:
    argocd.argoproj.io/hook: PostSync
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: smoke
          image: curlimages/curl:latest
          command: ["sh", "-c", "curl -sf http://api:8080/healthz"]

If curl fails (e.g. non-zero exit code), the hook job fails, and ArgoCD marks the sync as failed — a trigger that can fire notifications (episode 17) and open the door to automatic rollback.

#Closing

This episode united the whole flow: CI builds and tests artifacts then updates the manifests in Git, and ArgoCD as CD pulls the changes and reconciles the cluster. We covered the five build-stage steps, the kustomize edit set image pattern as the CI-to-CD bridge, the sync policy comparison, examples on GitHub Actions, GitLab, Jenkins, and Tekton, and testing strategies with PostSync hooks.

The points you should take with you:

• CI produces immutable artifacts; CD (ArgoCD) applies configuration from Git.
• Never call sync from a pipeline — let ArgoCD pull from Git.
• Tag images with a commit SHA for reproducibility and easy rollback.
• Promotion pipelines use the same tag across all environments.
• PostSync hooks provide a verification gate after deployment.

The "fast and traceable" flow is now ready. But fast isn't enough — in production you need a way to release a new version without cutting off users. In the next episode 19 we discuss progressive delivery with Argo Rollouts — canary, blue-green, metric analysis, and traffic splitting. See you in episode 19!