Params & Results

A named input declared in a Task or Pipeline spec and given a value by the TaskRun, PipelineRun or pipeline task that uses it.

Params are how one Task definition serves many runs: the repo URL, the image tag, the target environment. They are declared with a name, a type and optionally a default and description.

Tekton replaces $(params.x) and other $(…) expressions with their values in the spec before it creates TaskRuns and Pods.

It is text replacement, not a template language: no loops, no conditionals, no escaping. The container receives the final strings, which is both simple and the root of the injection problem.

Every param is a string, an array of strings or an object of string values; string is the default.

The declared type is checked against what the run supplies, and it decides which reference forms are legal: .key for objects, [*] or [i] for arrays.

The value a param takes when the run does not supply one; a param without a default is required.

Defaults keep PipelineRuns short and make Tasks reusable. Leaving a default off is how a Task says "you must tell me this", and the run fails validation if nobody does.

A list of allowed values for a string param; any other value fails the run before it starts (beta).

It moves input checking from a shell `case` statement into the spec, where it is visible, documented and enforced before a Pod is ever scheduled.

A param holding a list of strings, expanded into separate list items with $(params.name[*]) or indexed with $(params.name[i]).

[*] only works as a whole element of a list field like args or command, and each item becomes its own argv entry. That is safer than joining flags into one string and letting a shell split it.

A param with named string keys declared under properties, read one key at a time with $(params.name.key).

It groups related values (registry, name, tag) into one input. The run must supply every declared key, or the PipelineRun fails with ObjectParameterMissKeys.

Before creating any TaskRun, the controller checks that required params are present, types match, enum values are allowed and object keys are complete.

A bad input fails fast with a specific reason instead of a confusing error ten minutes into a build. No Pod, no wasted node time.

With inline specs (pipelineSpec, taskSpec), params of the outer run are visible to inner specs without being declared or passed at each level.

It removes boilerplate from fully inline PipelineRuns. It does not cross a taskRef: a referenced Task only sees params it declares and that are passed to it. Inner explicit values win over outer ones, and runtime values win over defaults.

A small named output a Task declares and its steps write to a file, which Tekton copies into TaskRun.status.results.

Results are how tasks hand values to each other without sharing a volume: a digest, a commit SHA, a URL. Declaring a result does not force a step to write it.

$(results.name.path) resolves to /tekton/results/name, a file on a volume shared by all steps of the Pod.

Writing the file is the whole API: any language, any tool. Use printf or echo -n, because a trailing newline becomes part of the value.

The Kubernetes mechanism Tekton uses by default to ship results: the entrypoint writes them as JSON to /tekton/termination, and the kubelet copies it into the Pod status.

It needs no extra permissions, but Kubernetes caps a container's message at 4096 bytes and each step reports all results written so far, so a Task's results share about 4 KB. Overflowing fails the step and the TaskRun.

An alternative transport where a sidecar prints result files to its log and the controller reads them from the Pod logs.

It lifts the shared 4 KB ceiling, at the cost of the controller needing pods/log access and extra work per TaskRun. Turned on with results-from: sidecar-logs in the feature-flags ConfigMap.

The per-result byte cap that applies in sidecar-logs mode, 4096 by default.

Raising it allows bigger results, but everything still lands in the TaskRun object in etcd, which is limited to about 1.5 MB. A result over the cap fails the TaskRun with TaskRunResultLargerThanAllowedLimit.

$(tasks.build.results.digest) in another pipeline task's params or when expressions, resolved by the PipelineRun controller.

Referencing a result creates a DAG edge: the consumer waits for the producer, no runAfter needed. If the producer never wrote it, the PipelineRun fails with InvalidTaskResultReference.

Outputs a Pipeline declares from its tasks' results, surfaced in PipelineRun.status.results.

They make a whole Pipeline usable like a function: whatever triggered it (a human, Triggers, Chains, another system) can read the image digest without digging into TaskRuns.

Results declared as type array or object, written as JSON and consumed with [*], [i] or .key.

They avoid ad-hoc comma-separated strings. The step must write valid JSON of the declared shape (strings only, every declared key), or the TaskRun fails.

Results declared on a single step, written to $(step.results.name.path) and read by later steps as $(steps.step-name.results.name).

They let steps, especially reusable StepActions, pass values within a Task. A Task result can be filled from one: value: $(steps.fetch.results.sha).

Built-in substitutions describing the run itself, such as $(context.taskRun.name), $(context.pipelineRun.uid) and, in finally tasks, $(tasks.status).

They give unique names, retry counts and outcomes without passing them as params. Each is only legal in certain places, and misspelt ones are rejected by validation.

Because substitution is raw text, a param value spliced into a script becomes shell code if it contains quotes, ;, && or $(…).

Branch names and PR titles from webhooks are attacker-controlled. Pass params into scripts through env vars (env: value: $(params.x)) and quote "$X": the script text never changes and the value stays data.