Skip to content

GitOps Full Loop

Connect Tekton (CI) and ArgoCD (CD) into a complete pipeline: code change triggers a build, build updates a manifest, ArgoCD deploys the update.

Time: ~25 minutes Difficulty: Advanced

Resources: This demo needs ~2GB RAM (Tekton + ArgoCD overhead). Clean up other demos first: task clean:all

  • How Tekton and ArgoCD connect in a GitOps workflow
  • The two-repo model: source repo (Tekton watches) and config repo (ArgoCD watches)
  • Writing a Tekton Pipeline with multiple tasks
  • Defining an ArgoCD Application custom resource
  • Walking through the full CI/CD loop step by step
Git Push --> Tekton Pipeline --> Push to Registry --> ArgoCD detects --> Deploys to cluster
(test + build) (simulated) config change (sync)

The two-repo model:

Source Repo (app code) Config Repo (K8s manifests)
| |
v v
Tekton watches for changes ArgoCD watches for changes
| |
v v
Pipeline: test -> build -> update ArgoCD: detect diff -> sync -> deploy
| ^
+--- updates image tag in config repo --+

In this demo, we simulate both repos within the cluster using ConfigMaps and local resources. The concepts translate directly to real Git repositories.

This demo requires Tekton and ArgoCD to be installed in your cluster. If you have not set them up yet:

  1. Tekton: Install from Tekton Basics or run:

    Terminal window
    kubectl apply -f https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml
  2. ArgoCD: Install from ArgoCD or run:

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

Verify both are running:

Terminal window
kubectl get pods -n tekton-pipelines
kubectl get pods -n argocd

Navigate to the demo directory:

Terminal window
cd demos/gitops-full-loop
Terminal window
kubectl apply -f manifests/namespace.yaml

Step 2: Deploy the application source (simulated source repo)

Section titled “Step 2: Deploy the application source (simulated source repo)”
Terminal window
kubectl apply -f manifests/app-source.yaml

Step 3: Deploy the application that ArgoCD will manage

Section titled “Step 3: Deploy the application that ArgoCD will manage”
Terminal window
kubectl apply -f manifests/deployment.yaml
Terminal window
kubectl apply -f manifests/tekton-pipeline.yaml
Terminal window
kubectl apply -f manifests/argocd-app.yaml
Terminal window
# Check the application is running
kubectl get pods -n gitops-demo
# Check the Tekton Pipeline exists
kubectl get pipeline -n gitops-demo
# Check ArgoCD sees the application
kubectl get applications -n argocd
# Access the app
kubectl port-forward svc/gitops-app 8080:80 -n gitops-demo

Open http://localhost:8080 to see the nginx welcome page with custom content.

Here is what happens in a real GitOps workflow, and how each piece maps to this demo:

In production, a Git webhook triggers Tekton. In this demo, we manually start the pipeline:

Terminal window
kubectl create -f - <<EOF
apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
generateName: gitops-pipeline-run-
namespace: gitops-demo
spec:
pipelineRef:
name: gitops-pipeline
workspaces:
- name: shared-workspace
emptyDir: {}
EOF

Watch the pipeline execute:

Terminal window
kubectl get pipelinerun -n gitops-demo -w

The pipeline runs three tasks in sequence:

  • validate-source: Checks that the source files exist and are valid
  • build-image: Simulates building and pushing a container image
  • update-manifests: Simulates updating the deployment manifest with a new image tag

In production, ArgoCD polls the config repo (default every 3 minutes) or receives a webhook. When it detects the manifests have drifted from the live state, it syncs.

Check ArgoCD status:

Terminal window
kubectl get applications -n argocd

ArgoCD applies the updated manifests to the cluster. The Deployment rolls out new pods with the updated image.

Terminal window
kubectl get pods -n gitops-demo -w
manifests/
namespace.yaml # gitops-demo namespace
app-source.yaml # ConfigMap simulating source repo (index.html + nginx.conf)
tekton-pipeline.yaml # Pipeline with 3 tasks: validate, build, update
argocd-app.yaml # ArgoCD Application CR pointing to gitops-demo
deployment.yaml # nginx Deployment + Service that ArgoCD manages

Tekton handles the CI side: it validates source, builds images, and updates manifests. Each task runs in its own pod. The pipeline defines the order and data flow between tasks.

ArgoCD handles the CD side: it watches for manifest changes and applies them to the cluster. It continuously reconciles the desired state (Git) with the actual state (cluster).

The connection point between CI and CD is the manifest update. Tekton updates the image tag in the deployment manifest, and ArgoCD detects that change and deploys it.

  1. Check the Tekton PipelineRun logs:

    Terminal window
    kubectl get pipelinerun -n gitops-demo
    # Use the name from above
    kubectl logs -n gitops-demo -l tekton.dev/pipeline=gitops-pipeline --all-containers
  2. Trigger another pipeline run and watch the full flow:

    Terminal window
    kubectl create -f - <<EOF
    apiVersion: tekton.dev/v1
    kind: PipelineRun
    metadata:
    generateName: gitops-pipeline-run-
    namespace: gitops-demo
    spec:
    pipelineRef:
    name: gitops-pipeline
    workspaces:
    - name: shared-workspace
    emptyDir: {}
    EOF
  3. Force an ArgoCD sync:

    Terminal window
    kubectl patch application gitops-app -n argocd \
    --type=merge -p '{"operation":{"sync":{"revision":"HEAD"}}}'
  4. View ArgoCD in the UI:

    Terminal window
    kubectl port-forward svc/argocd-server 8443:443 -n argocd

    Open https://localhost:8443 (accept the self-signed cert).

Terminal window
kubectl delete namespace gitops-demo
kubectl delete application gitops-app -n argocd

Note: This only removes the demo resources. Tekton and ArgoCD remain installed for other demos.

See docs/deep-dive.md for details on the two-repo model, webhook configuration, ArgoCD sync policies, Tekton triggers, image promotion strategies, and production GitOps patterns.

Move on to Multi-Tenant to explore namespace isolation and resource quotas for multi-team clusters.