What are Tekton Parameters and how do you pass values to Tasks?

Parameters in Tekton work like function arguments in programming. The Task definition is the function signature that declares what inputs it expects, and the TaskRun is the function call that supplies the actual values. Just as a function deploy(service_name, environment) can be called with deploy('payments-api', 'staging') or deploy('checkout-service', 'production'), a parameterized Tekton Task can build and deploy any service without modifying the Task itself.

Tekton Parameters are declared in the params section of a Task or Pipeline spec. Each parameter has a name, a type (string or array), an optional description, and an optional default value. Within the Task's steps, parameters are referenced using the syntax $(params.<name>). When you create a TaskRun, you provide values for these parameters in the params section of the TaskRun spec. If a parameter has a default value and the TaskRun does not provide one, the default is used. If a parameter has no default and no value is provided, the TaskRun creation fails with a validation error. For example, the payments-api team defines a build-image Task with parameters for git-url, git-revision, and image-tag. Each time they create a TaskRun, they supply the specific branch and tag values for that build.

Parameters flow through the Tekton resource hierarchy in a structured way. A Pipeline declares its own parameters, which are separate from the parameters of the Tasks it contains. To pass a Pipeline-level parameter down to a Task, you explicitly map it in the Pipeline's task definition using the $(params.<name>) syntax. This explicit mapping prevents naming collisions and makes the data flow visible and auditable. The order-processing-service team defines a Pipeline with parameters for git-url, target-environment, and image-registry. Inside the Pipeline, the git-url parameter is mapped to the clone Task's url parameter, and the image-registry parameter is mapped to the build Task's destination parameter. This layered approach means changing the target environment is a single parameter change in the PipelineRun, not an edit to the Pipeline or Task definitions.

In production, parameters are the key mechanism for making Tasks and Pipelines reusable. The platform engineering team at a company running the user-auth-service, inventory-sync, and checkout-service creates a single generic-build-pipeline with parameters for the repository URL, branch, image registry, deployment namespace, and replica count. Each application team creates their own PipelineRuns with application-specific parameter values, all sharing the same Pipeline definition. This reduces duplication and ensures consistency: when the platform team adds a new security scanning step to the Pipeline, all application teams automatically get it on their next run. Parameters of type array are useful for passing multiple values, such as a list of test suites to run or a list of namespaces to deploy to.

A gotcha that trips up beginners is the difference between Tekton parameters and Kubernetes environment variables. Parameters are resolved at pipeline creation time by the Tekton controller and injected into the step scripts as literal string substitutions. They are not environment variables and cannot be accessed using $VAR syntax inside the container unless you explicitly set them as env vars in the step definition. Another common mistake is trying to use parameter values computed at runtime (like the output of a shell command) as input to another parameter. Parameters are static values set at TaskRun or PipelineRun creation time. For dynamic values computed during execution, use Tekton Results instead, which allow a step to write a value that a subsequent Task can consume.