Tekton Helm Deploy Task: Install Charts in Pipelines (2026)

Tekton’s Helm Deploy Task is the swiss army knife for integrating Helm chart deployments directly into your Tekton pipelines, allowing you to manage Kubernetes application lifecycles as code.

Here’s a simple Helm chart deployment using the helm-deploy task:

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: helm-deploy-example-run
spec:
  taskRef:
    name: helm-deploy
  params:
    - name: release-name
      value: "my-app"
    - name: chart-path
      value: "charts/my-app" # Path to your Helm chart in the workspace
    - name: namespace
      value: "default"
    - name: helm-version
      value: "3" # Use Helm v3
    - name: action
      value: "upgrade" # Can be "install" or "upgrade"
    - name: values-file
      value: "my-values.yaml" # Optional: path to a values file in the workspace
  workspaces:
    - name: source
      persistentVolumeClaim:
        claimName: my-git-repo-pvc # PVC containing your chart and values file

This TaskRun will execute the helm-deploy task, which in turn uses Helm to perform an upgrade (or install if the release doesn’t exist) of the my-app chart into the default namespace. It will look for the chart in the charts/my-app directory within the source workspace and use my-values.yaml for configuration.

The Problem It Solves

Managing application deployments in Kubernetes often involves complex Helm charts. Traditionally, these deployments are handled by separate CI/CD tools or manual kubectl commands. This creates a disconnect between your pipeline and your deployments. The helm-deploy task bridges this gap by allowing you to declare your Helm chart installations and upgrades as first-class citizens within your Tekton pipelines. This ensures that your deployments are versioned, auditable, and fully integrated into your CI/CD workflow.

How It Works Internally

The helm-deploy task is essentially a wrapper around the helm CLI. When you define a TaskRun for helm-deploy, Tekton spins up a pod with the helm binary installed. The task then executes the specified Helm command (helm install or helm upgrade) with the provided parameters, such as the release name, chart path, namespace, and any custom values files. It mounts the specified workspace (usually a Git repository) so that Helm can access the chart files and any associated configuration.

Levers You Control

1. release-name: The name for your Helm release. This is how Helm tracks deployed applications.
2. chart-path: The directory within your workspace containing the Helm chart (e.g., charts/my-app).
3. namespace: The Kubernetes namespace where the release will be installed or upgraded.
4. helm-version: Specifies whether to use Helm v2 or v3. Helm v3 is recommended for its improved architecture.
5. action: Determines whether to install a new release or upgrade an existing one. If upgrade is chosen and the release doesn’t exist, Helm will perform an install.
6. values-file: An optional path to a YAML file within your workspace that contains custom values to override the chart’s defaults.
7. set-values: A string for passing individual key-value pairs directly on the command line (e.g., image.tag=v1.2.3).
8. credentials-file: Path to a kubeconfig file if you need to deploy to a different cluster than the one Tekton is running on.

The One Thing Most People Don’t Know

Many users assume that helm upgrade will only update if there are actual changes detected in the chart or values. However, Helm’s upgrade command, by default, will always perform an operation if the action is specified as upgrade, even if no differences are found. If you want to avoid unnecessary operations and ensure that an upgrade only happens when there’s a meaningful change, you typically need to manage the desired state outside of the helm upgrade command itself and conditionally execute it, or leverage Helm’s diff plugin in a preceding task to check for changes before running the upgrade.

The next concept you’ll likely explore is how to integrate this task into a full CI/CD pipeline, including building container images and testing deployments.