Tekton Parameter Types: String, Array, and Object Params (2026)

Tekton’s parameter types don’t just hold data; they act as fundamental building blocks for dynamic and reusable pipeline logic, allowing you to inject behavior into your tasks, not just static values.

Let’s see this in action. Imagine a git-clone task that needs to know which branch to check out. Instead of hardcoding it, we’ll use a parameter.

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: git-clone
spec:
  params:
    - name: repo-url
      type: string
      description: The URL of the Git repository.
    - name: revision
      type: string
      description: The branch or commit to check out. Defaults to 'main'.
      default: 'main'
  steps:
    - name: clone
      image: alpine/git
      script: |
        git clone $(params.repo-url) .
        git checkout $(params.revision)

Now, when we run a Pipeline that uses this task, we can provide the revision parameter:

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: my-app-build
spec:
  tasks:
    - name: clone-repo
      taskRef:
        name: git-clone
      params:
        - name: repo-url
          value: 'https://github.com/my-org/my-app.git'
        - name: revision
          value: 'develop' # We're telling it to check out the 'develop' branch!

This git-clone task can now be used across many pipelines, checking out different branches or commits simply by changing the parameter value. This is the power of parameterization: making your tasks and pipelines adaptable without code duplication.

Beyond simple strings, Tekton supports array and object types. Arrays are perfect for lists of items, like multiple arguments to pass to a script, or a list of files to process. Objects are ideal for structured data, such as configuration settings or metadata.

Consider a task that deploys an application to different environments. We could pass an object containing environment-specific details:

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: deploy
spec:
  params:
    - name: app-name
      type: string
    - name: env-config
      type: object
      description: Configuration for the deployment environment.
  steps:
    - name: configure-deployment
      image: ubuntu
      script: |
        echo "Deploying $(params.app-name) to $(params.env-config.environment)"
        echo "  Region: $(params.env-config.region)"
        echo "  Instance Type: $(params.env-config.instance_type)"

And here’s how you’d pass an object parameter:

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: deploy-staging
spec:
  pipelineRef:
    name: my-deployment-pipeline # Assuming a pipeline that uses the deploy task
  params:
    - name: app-name
      value: 'my-web-service'
    - name: env-config
      value: | # YAML value for the object parameter
        {
          "environment": "staging",
          "region": "us-west-2",
          "instance_type": "t3.medium"
        }

Notice how we access nested values using dot notation: $(params.env-config.environment). This makes complex configurations manageable and type-safe.

The real magic happens when you combine parameter types. An array of objects, for instance, could represent a list of microservices to deploy, each with its own configuration. Or a string parameter could be a JSON string that you later parse within a script.

Tekton’s parameter system is designed to make your CI/CD workflows more flexible, maintainable, and powerful. It shifts the focus from static, monolithic scripts to composable, configurable building blocks.

One subtle but powerful aspect is how default values interact with parameter resolution. If a parameter is declared with a default and not provided in a PipelineRun or task invocation, that default value is used. However, if a parameter is marked as required: true and no value is provided, Tekton will error. This allows you to enforce the presence of critical configuration without needing to explicitly check for it in every task.

The next step in mastering Tekton’s dynamic capabilities is understanding how to bind parameters from one task’s output to another task’s input.