Glossary

The folder Pipelines-as-Code scans on each event for PipelineRun YAML files to match.

Each file is one candidate PipelineRun; annotations on it decide whether it runs for this event.

The shared directory a step writes a result into, via $(results.<name>.path).

At the end of the Pod the controller collects these small values into the TaskRun status so other Tasks can use them.

Child TaskRuns are named after the run and the pipeline task, labelled tekton.dev/pipelineRun and tekton.dev/pipelineTask, and owned by the PipelineRun.

The owner reference means deleting the PipelineRun garbage-collects its TaskRuns and Pods. The labels let you select every TaskRun of a run with kubectl get tr -l tekton.dev/pipelineRun=….

The three roots a binding value can read: the JSON body (JSONPath-like, with [i] indexes), HTTP headers (case-insensitive), and interceptor extensions.

Values can be mixed with literals ("pr-$(body.number)"), and $(body) on its own gives the whole payload as a JSON string. A path that doesn't exist fails the binding for that event.

A variable available only to finally tasks: Succeeded, Failed or None (skipped or not run) for one DAG task.

It lets a finally task report, or use a when guard, on how a specific task went without parsing logs.

The aggregate status of all DAG tasks, readable in finally: Succeeded, Failed, Completed (succeeded with some skipped) or None.

The standard way to send a Slack message only on failure: `when: [{input: $(tasks.status), operator: in, values: [Failed]}]`.

The placeholder syntax inside resourcetemplates that is replaced with the bound or default value of a template param.

A param that is neither bound nor defaulted is not an error: the literal placeholder ends up in the created object, which then fails later in a confusing way.

Resolves to "true" or "false" depending on whether an optional workspace was bound.

Scripts branch on it, and Pipelines use it in when expressions to skip tasks that need the workspace. When unbound, the path variable resolves to an empty string.

Every TaskRun executes as one ordinary Pod that the Kubernetes scheduler places on a node.

There are no long-lived build agents to size, patch or keep warm: capacity is the cluster's, it bin-packs by resource request, and it scales with the node pool.

ReadWriteOnce volumes can be attached to one node at a time; ReadWriteMany volumes can be mounted from many nodes.

Most block-storage classes are RWO only. Parallel TaskRun Pods scheduled to different nodes then stall with a Multi-Attach error, which is why Tekton co-schedules them.

An HTTPS hook the API server calls before storing an object: mutating (defaulting) first, then validating.

Tekton's webhook rejects bad YAML (missing image, unknown variable, gated field) when you apply it, not minutes later when a Pod fails. It also fills defaults such as timeout and serviceAccountName.

A placeholder StatefulSet Pod the controller creates per PVC workspace (or per PipelineRun); TaskRun Pods get pod affinity to it.

It pins every Pod that shares the volume to the same node, so an RWO PVC can be used by parallel tasks. The cost: those Pods compete for one node's capacity.

A custom task (e.g. the manual-approval-gate ApprovalTask) that blocks the pipeline until enough named approvers approve it.

A human gate before production, enforced inside the PipelineRun instead of by convention. A rejection or timeout fails the CustomRun and stops the run.

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.

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.

The CNCF package index (artifacthub.io) where the Tekton catalog is now published, as tekton-task and tekton-pipeline packages.

Tekton Hub (hub.tekton.dev) is deprecated; the hub resolver defaults to type artifact and the tekton-catalog-tasks catalog.

A signed statement about one or more artifacts, here an in-toto Statement wrapped in a DSSE envelope and signed by Chains.

Signing binds the claim to a key or identity, so anyone holding the public key can detect a modified or forged document.

A feature flag (default true) that makes the first step wait until every sidecar is ready.

Readiness is signalled through a downward-API file the first step's entrypoint waits on. Turning it off speeds up starts in clusters that cannot provide the volume, at the cost of steps racing their sidecars.

A kubernetes.io/basic-auth Secret (username + password/token), usable for git over https or a registry.

For git it becomes a [credential] entry plus a line in ~/.git-credentials used by the store helper. For docker it becomes an auths entry.

Pulls an OCI image (bundle param) and returns the layer whose annotations match the requested kind and name.

Registries give you immutable digests, replication and access control for free, so bundles are the easiest way to pin and distribute Tasks.

Patching spec.status to TaskRunCancelled (what tkn taskrun cancel does) stops the run.

Cancellation is declarative like everything else: you change the spec and the controller acts. It marks the run False/TaskRunCancelled and deletes the Pod, taking its logs with it unless you store them elsewhere.

Graceful cancel: running DAG TaskRuns are cancelled, unstarted ones are skipped, then finally tasks run.

Stop now, but still release locks, delete preview environments and notify.

When an owner is deleted the garbage collector deletes its dependents, in background (default), foreground, or not at all (orphan).

Pruning old PipelineRuns is enough to reclaim their TaskRuns and Pods. Run history therefore lives in etcd only until you prune it, which is why Tekton Results exists.

An alternative `cel:` field holding a Common Expression Language expression, e.g. `'$(params.branch)'.startsWith('release/')`.

It handles ranges, prefixes, regexes and boolean logic that in/notin can't. Behind the `enable-cel-in-whenexpression` feature flag (alpha); params are substituted as text, so string references need quotes.

Evaluates a Common Expression Language filter over body and header. The event continues only if it returns true.

Branch, path and action filtering without writing a service. Triggers adds functions such as match, truncate, split, compareSecret and parseJSON to standard CEL.

Key/expression pairs on the CEL interceptor whose results are added to the event's extensions.

Bindings can only copy fields. Overlays compute new ones (a 7-char SHA, a branch name without refs/heads/) so the template stays simple.

The ConfigMap in tekton-chains that sets per-artifact-type format, storage and signer, plus transparency, builder id and signer options.

Everything about Chains' output is configuration, not Task code: switch formats or add a backend without touching a pipeline.

Fetches a Task or Pipeline from another namespace of the same cluster by kind, name and namespace, subject to allowed and blocked namespace lists.

It replaces the deprecated ClusterTask: a platform team keeps shared Tasks in one namespace, and the resolver config controls who can read from where.

A cluster-scoped CRD that registers an interceptor as an HTTPS service. The listener POSTs it an InterceptorRequest and reads back an InterceptorResponse.

The built-in github, gitlab, bitbucket, cel and slack interceptors are ClusterInterceptors served by tekton-triggers-core-interceptors. You can register your own the same way via spec.clientConfig.service.

A cluster-scoped Task kind from the v1beta1 era, deprecated and removed in recent releases.

To share a Task across namespaces now, keep it in one namespace and reference it with the cluster resolver, or fetch it from git, a bundle or the Hub.

A cluster-scoped TriggerBinding that any Trigger in any namespace can reference with kind: ClusterTriggerBinding.

Mappings for a provider's payload are the same everywhere, so you define them once. A ref without kind looks for a namespaced TriggerBinding in the Trigger's own namespace, which is a common cause of 'not found'.

The container-style alternative to script: an executable and its arguments.

They are passed to the entrypoint after --. If you give only args, the controller looks up the image's ENTRYPOINT from the registry so it knows what to run.

A ConfigMap in tekton-pipelines holding cluster-wide defaults applied by the defaulting webhook.

default-timeout-minutes (60) and default-service-account (default) are why a TaskRun you never gave a timeout still has one.

Bind a ConfigMap or Secret so its keys appear as read-only files in the workspace.

Config and credentials arrive as files the tools already understand, chosen by the run rather than hard-coded in the Task.

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.

The Linux Foundation project that hosts Tekton, alongside Jenkins, Spinnaker and others.

Vendor-neutral governance is why Tekton serves as the engine under several products (OpenShift Pipelines and Jenkins X among them) and why its API is meant as a common standard.

A long-running process that watches resources through informers and works to make the actual state match the declared one.

Tekton's tekton-pipelines-controller is the only Tekton process on the run path. It does not execute builds; it creates Pods and lets the kubelet run them.

Prometheus metrics exposed by the controller, such as pipelinerun_duration_seconds (histogram) and running_pipelineruns (gauge), all prefixed tekton_pipelines_controller_.

Duration percentiles and running counts are the first signal of a slow registry, an overloaded cluster or a stuck controller. config-observability controls levels and histogram vs last-value.

Performance knobs: kube-api-qps and kube-api-burst limit the controller's client-side API rate; threads-per-controller sets workqueue workers.

Defaults are conservative. Under a spike of runs the rate limiter, not CPU, is usually the bottleneck, so raise QPS and burst before adding threads.

Chooses the co-scheduling policy: workspaces (default), pipelineruns, isolate-pipelinerun, or disabled.

workspaces pins per PVC and rejects a task binding two PVC workspaces; pipelineruns pins a whole run to one node; isolate-pipelinerun additionally keeps one run per node; disabled leaves placement to the scheduler.

Before the first step, Tekton turns the SA's annotated Secrets into ~/.gitconfig, ~/.git-credentials, ~/.ssh/* and ~/.docker/config.json under /tekton/creds, then copies them into each step's $HOME.

Tools like git and crane pick credentials up with no Task changes. The flip side: every attached secret lands in every step, whether that step needs it or not.

The chain of dependent tasks with the largest total duration. With unlimited capacity it equals the PipelineRun's wall-clock time.

Making a task faster only helps if it is on the critical path. Speeding up anything else just gives it more slack.

An instance of a CRD: one Task, one PipelineRun, stored in etcd like any other object.

Definitions (Task, Pipeline) and executions (TaskRun, PipelineRun) are separate objects. You keep the first in Git and create the second each time something should run.

A pipeline task whose taskRef names a foreign apiVersion/kind; Tekton creates a CustomRun and an external controller drives it to a Succeeded condition.

Extends control flow without forking Tekton: waits, approvals, loops over pipelines, or calls to external systems, all scheduled like normal tasks.

A Kubernetes object that adds a new resource type, such as Task or PipelineRun, to the API server.

Because Tekton's types are CRDs, kubectl, RBAC, namespaces, labels, watches and GitOps tools all work on pipelines exactly as they do on Deployments. There is no separate Tekton API or database.

Validation that rejects a Pipeline whose edges form a loop, and also catches runAfter pointing at a task that doesn't exist.

A cycle has no valid order: every task in it waits on another. The admission webhook rejects it on kubectl apply. A Pipeline that arrives through a resolver fails the PipelineRun instead (PipelineValidationFailed), before any TaskRun is created.

Building container images inside a step without a Docker daemon or privileged mode.

kaniko drops the privileged flag but still runs as root, rootless buildah needs privilege escalation for user namespaces, and ko/jib need nothing special because they never run RUN instructions.

The graph of pipeline tasks and their edges, built when the run starts.

Edges only point forward, so there is always an order in which every task's parents finish first. The controller walks this graph on every reconcile to find what is ready to run.

An alpha TaskRun option that keeps a failed step's container alive instead of ending the run.

You can kubectl exec into the exact environment that failed, then run debug-continue or debug-fail-continue from /tekton/debug/scripts to let the run go on. This beats guessing from logs.

The default-pod-template key in the config-defaults ConfigMap, merged under every TaskRun's podTemplate.

Cluster-wide defaults like proxies, pull secrets or a non-root securityContext. Fields are replaced wholesale by higher layers; env and volumes merge by name.

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 config-defaults setting capping how many combinations one matrix may produce (256 by default).

A matrix that would exceed it fails validation, which protects the cluster from a typo that creates thousands of Pods.

An admission controller (Sigstore policy-controller, Kyverno verifyImages, Gatekeeper with a provider) that verifies attestations before a Pod is admitted.

Provenance nobody checks protects nothing. The policy is where you require the Chains key and, for example, a specific builder.id or source repo.

A free-text label on a Pipeline or a pipeline task, shown by tkn and the Dashboard.

Task names must be DNS-label-safe and stay stable because results refer to them. displayName lets humans read "Build the binary" without renaming the node.

Optional human-readable labels on Tasks, steps and params.

UIs like the Dashboard show them instead of the DNS-safe name; they change nothing about execution.

A kubernetes.io/dockerconfigjson Secret holding a full Docker config; attached to the SA, its auths are merged into ~/.docker/config.json.

No annotation needed. Not the same thing as imagePullSecrets, which the kubelet uses to pull step images.

A scratch volume created with the Pod and deleted with it.

It is shared by the steps of one TaskRun but not across tasks of a Pipeline: each TaskRun is a separate Pod and gets a fresh empty directory.

The flag that sets which API fields the webhook accepts: stable, beta (the shipped default) or alpha.

Alpha fields may change or disappear; beta fields follow a gentler policy; stable fields are covered by the v1 compatibility promise. Gating them per cluster keeps production on a known surface.

A step env var whose value comes from a Secret key; the Pod spec shows only the reference.

Convenient for tools that only read env vars, but env is inherited by child processes and easily printed. Tekton does not redact secrets in logs.

A CRD for a long-running HTTP sink that receives events and evaluates every Trigger it serves against each one.

It is the only part that is always running. It replies 202 Accepted right away and processes the event asynchronously, so a 202 from the listener does not mean a PipelineRun was created.

For each EventListener the controller creates a Deployment and a Service named el-<name>, listening on port 8080.

The Service is ClusterIP by default, so you must expose it yourself (Ingress, OpenShift Route or a LoadBalancer serviceType) before GitHub can reach it. Replicas scale the sink horizontally, and cloudEventURI makes it emit CloudEvents about each event it handles.

Kubernetes Events the controller emits on runs (Started, Running, Succeeded, Failed) and its structured JSON logs keyed by namespace/name.

Events explain one run's story; logs explain what the controller decided and why. Both are short-lived, so ship them somewhere if you need them later.

One task that runs after several parents, e.g. build after lint and unit-test.

A fan-in task waits for its slowest parent, so a single slow branch holds up everything downstream of the join.

One task with several children that become ready together, e.g. lint, unit-test and e2e all after clone.

This is where Pipelines get their speed: independent children run as parallel Pods. The cost is cluster capacity, since every branch is a Pod with its own resource requests.

The ConfigMap that switches Tekton behaviours and API fields on or off for the whole installation.

It controls stability gates and runtime choices such as await-sidecar-readiness, results-from and coschedule. Two clusters with different flags can accept different YAML.

Tasks under `spec.finally` that run in parallel once every DAG task has finished, whether it succeeded, failed or was skipped.

The place for cleanup, notifications and reporting. A failing finally task fails the PipelineRun even if every DAG task passed.

metadata.generateName asks the API server to add a random 5-character suffix, so every created PipelineRun gets a unique name.

A fixed name works once and then fails with AlreadyExists. A name derived from the commit SHA dedupes redeliveries but blocks reruns. generateName never collides, but builds a redelivered commit twice.

Fetches one file (pathInRepo) at a revision, either by anonymous clone of url or through the SCM provider API using org/repo and a token Secret.

The most common way to keep Tasks next to the code that uses them. Clone mode is simple; API mode works with private repos but counts against provider rate limits.

The most used catalog Task: clones url at revision into the output workspace and emits commit and url results.

Almost every pipeline starts with it, and its commit result is what downstream tasks and provenance use to say exactly which source was built.

Validates X-Hub-Signature-256 against a secret and filters on X-GitHub-Event with an eventTypes list.

Without it, anyone who finds your webhook URL can start pipelines with any payload they like. eventTypes keeps push-only Triggers from firing on ping or issue events.

Provider-specific equivalents of the GitHub interceptor. GitLab compares the X-Gitlab-Token shared token; Bitbucket Server checks an HMAC in X-Hub-Signature.

Each provider authenticates and names events differently (Push Hook, repo:refs_changed). The interceptor hides that so the rest of the chain looks the same.

PR comments that drive CI: /retest, /test <name>, /cancel, and /ok-to-test to approve a run for an untrusted author.

Running a fork's PR means running a stranger's code with your credentials, so it waits for a maintainer; comments from users outside the ACL are ignored.

Running several controller replicas that split the key space into buckets, each guarded by a Lease that one replica holds at a time.

With one bucket only one replica works and the rest wait. More buckets spread the load, and a crash stalls only the dead replica's share until its leases expire.

sha256=HMAC-SHA256(secret, raw body), sent in X-Hub-Signature-256 and recomputed by the interceptor.

It proves the sender knows the secret and that the body wasn't changed in transit. One changed byte gives a completely different digest, and the comparison is constant-time so timing doesn't leak the expected value.

Fetches a resource from any HTTPS URL, with optional basic auth from a Secret.

Handy for internal file servers, but a URL is not a version: unless the URL itself is immutable, the content can change under you.

Fetches a catalog Task or Pipeline by catalog, kind, name and version from Artifact Hub (type: artifact) or the older Tekton Hub API (type: tekton).

The shortest way to use community Tasks such as git-clone or buildah, at the price of trusting the hub and the publisher at fetch time.

The pair of string results catalog build Tasks (kaniko, buildah) already emit: the image reference and its sha256 digest.

Using the standard names gives you provenance for free with catalog Tasks. The digest must be the full sha256:<64 hex> form.

Secrets the kubelet uses to pull the step and sidecar images, set on the SA or in podTemplate.

Pulling the image that runs a step is the kubelet's job. Pushing an image from inside a step uses credential initialization or a workspace.

Referencing $(tasks.X.results.Y) in a task's params or when expressions makes it depend on X, with no runAfter needed.

Data dependencies order themselves. Sharing a workspace, though, does NOT create an edge: two tasks that write and read the same volume race unless you add runAfter.

The attestation envelope format: _type, a list of subjects (name + digest) and a typed predicate.

A standard wrapper means cosign, policy engines and other verifiers can read Chains output without knowing anything about Tekton.

Containers Tekton adds before the steps: prepare copies the entrypoint binary into a shared volume, place-scripts writes step scripts to /tekton/scripts, and working-dir-initializer creates workingDirs.

They set up the shared /tekton volumes that let ordinary images behave as ordered steps. While they run, the Pod is Pending and the TaskRun reason is Pending.

The structured form of a when expression: an `input` string (usually a param or result reference), an `operator` (`in` or `notin`) and a non-empty list of `values`.

The comparison is plain string matching after variable substitution. Referencing `$(tasks.x.results.y)` in `input` also makes the guarded task wait for x.

A step in a Trigger's chain that can validate, filter or enrich the event before bindings run. Any interceptor can stop the chain.

Interceptors run in order and each sees the extensions added by earlier ones. The chain stops at the first continue: false, so cheap checks like signature validation should come first.

Listing a workspace under specific steps[].workspaces or sidecars[].workspaces mounts it only into those containers.

Credentials can reach the one step that pushes, not every image in the Task. Workspaces that no step lists stay visible to all steps, as before.

The operator pruner's two retention rules: keep the newest N runs, or keep runs younger than M minutes. They are mutually exclusive.

The operator implements them as a CronJob, so objects still pile up between schedule firings. Keep N bounds the count; keep-since bounds age but lets busy days grow large.

Chains proves its workload identity with an OIDC token, Sigstore's Fulcio CA issues a short-lived certificate for an ephemeral key, and the key is discarded after signing.

No long-lived key to protect or rotate. Verifiers check the certificate identity and issuer instead of a public key, and rely on Rekor to show the signature was made while the cert was valid.

Signing through a cloud or Vault KMS key referenced by signers.kms.kmsref, so the private key never enters the cluster.

Removes key theft from the threat model and gives an audit log of every signing operation.

Give each pipeline task an SA that can do exactly its job: clone and build get no API rights, deploy gets a narrow Role.

One shared, powerful SA means every step, including third-party test code, holds a token that can deploy or read Secrets.

Acting on the current state (the level) rather than on the sequence of changes (the edges).

If the controller crashes or misses events, a fresh LIST and one reconcile per object are enough to catch up. Edge-triggered logic that counts events stays wrong forever after a miss.

Where Results keeps step logs after the Pods are gone: object storage like S3 or GCS, or a PVC.

Pod logs vanish with the Pod. Archiving them is what keeps a failed build debuggable a week later.

The inputs of the build: step images by digest, the Task source from refSource, and source repos given via CHAINS-GIT_URL/CHAINS-GIT_COMMIT or *ARTIFACT_INPUTS.

They let a verifier ask “which base image and which commit went into this?” and catch builds from unapproved sources or outdated images. They are called materials in SLSA v0.2 and resolvedDependencies in v1.0.

A field on a pipeline task that fans it out into one TaskRun (or CustomRun) per combination of its array params.

Build or test across platforms × versions without copy-pasting tasks. All combinations run in parallel, and the pipeline task fails if any of them fails.

Named extra entries: params not in the matrix are added to every combination or only to matching ones, and an entry that matches no combination becomes a new one.

Covers the irregular cases, like one extra flag for arm64 or one experimental platform, without blowing up the cartesian product.

Each fanned-out TaskRun emits its own string result; Tekton aggregates them into an array that downstream tasks read whole.

The usual fan-out/fan-in shape: build N images, then publish a single multi-arch manifest from `$(tasks.build.results.IMAGE[*])`.

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.

Where the workspace appears inside every step container; defaults to /workspace/<name>.

Scripts should use $(workspaces.<name>.path) rather than hard-coding the path, so the Task keeps working if someone overrides mountPath.

Selectors that let one EventListener serve Trigger CRDs from other namespaces (matchNames, "*") and/or only those with matching labels.

This is how platform teams run one listener for many teams. The listener's ServiceAccount must be allowed to read Triggers, bindings and templates in those namespaces, or they are silently skipped and the errors show up only in its logs.

Tekton creates every ready TaskRun immediately and has no per-pipeline concurrency limit. Throughput is bounded by namespace ResourceQuota and node capacity.

When a quota refuses a Pod, the TaskRun waits as Unknown/ExceededResourceQuota and the controller retries. A wide fan-out under a tight quota runs in waves. That is safe but slower, and the waiting counts against timeouts.

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.

Annotations that match a PipelineRun to an event type and target branch (globs allowed); on-cel-expression allows richer matching.

Matching happens before anything is created, so unmatched events cost nothing and you can keep separate runs for PRs, merges and tags.

Per-step policy for a non-zero exit: stopAndFail (default) or continue.

With stopAndFail, later steps are skipped and the TaskRun fails. With continue, the exit code is recorded and the next step runs anyway; useful for a lint step whose failure a later step reports.

Lets a pipeline task fail without stopping the PipelineRun; its TaskRun is still Failed but dependents run.

Useful for advisory checks like lint or a vulnerability scan that shouldn't block a deploy. The default is stopAndFail. Beta in recent releases.

A workspace declared optional: true may be left unbound by the run.

Lets one Task support an optional cache or credentials. A required workspace that isn't bound makes the run fail validation before any Pod starts.

metadata.ownerReferences on a child object pointing at the object that created it: Pod → TaskRun → PipelineRun.

Kubernetes' garbage collector follows these links. A taskRef by name is not ownership: deleting a Task leaves its past runs alone.

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.

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.

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.

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.

Bind an existing PVC by claimName; it outlives every run.

Good for a cache you deliberately keep. Dangerous as a build directory: concurrent runs write into the same files and later runs see earlier runs' leftovers.

Referencing an immutable identifier (commit SHA, image digest) instead of a moving one (branch, tag) so every run resolves the same bytes.

Branches change on every merge and tags can be force-moved, so unpinned refs silently pick up breaking or malicious changes. Pinning makes runs reproducible; upgrades become explicit commits.

A namespaced object (tekton.dev/v1) listing pipeline tasks, their ordering, and the params and workspaces they share.

It is a template, like a Task: it runs nothing until a PipelineRun points at it. Ordering is declared as data (edges), not as a script, which is what lets Tekton run independent work in parallel.

A Pipeline arranges Tasks into a graph; a PipelineRun executes it by creating one TaskRun per pipeline task.

The PipelineRun owns its TaskRuns, which own their Pods, so one object represents the whole run and deleting it cleans up everything beneath.

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.

An entry in spec.tasks: a name plus a taskRef or taskSpec, and optionally runAfter, params, workspaces, when, retries and timeout.

The pipeline task name, not the Task name, is the node in the graph. The same Task can appear many times under different names, and $(tasks.<name>.results.x) refers to that name.

A Pipeline declares its own workspaces and maps each pipeline task's workspace name to one of them.

Mapping several tasks onto the same pipeline workspace is how clone, build and test end up sharing one volume, even though each Task names its slot differently.

A PipelineRun pointing at a Pipeline by name or through a resolver (git, bundles, hub, cluster).

It lets many runs share one reviewed definition. The resolved spec is copied into status.pipelineSpec, so later edits to the Pipeline don't change a run in progress.

One execution of a Pipeline with concrete params and workspace bindings. It owns one TaskRun per pipeline task that runs.

It is both the request and the record. The controller reconciles it repeatedly, creating TaskRuns and summarizing their outcomes in a single Succeeded condition.

The Succeeded condition reasons: Running, PipelineRunStopping, Succeeded, Completed (succeeded with some tasks skipped), Failed, PipelineRunTimeout, Cancelled, PipelineValidationFailed…

As with TaskRuns, status True/False/Unknown says whether it finished, and the reason plus a message like "Tasks Completed: 4 (Failed: 1, Cancelled 0), Skipped: 2" says how.

An alpha feature (TEP-0056) where a pipeline task embeds a pipelineSpec, so the controller creates a child PipelineRun.

It lets you compose whole sub-pipelines (e.g. a security stage) as one node in a parent graph. It is alpha and only partly implemented, so check your release before relying on it.

A Tekton project that runs PipelineRuns kept in the repository's .tekton/ directory in response to Git provider events.

Pipeline definitions are versioned and reviewed with the code they build, and a PR can change its own CI.

A PipelineRun that carries its whole Pipeline definition.

Common for generated runs (Triggers templates, Pipelines-as-Code). The trade-off is the same as taskSpec: nothing to install, nothing to share.

The TaskRun Pod goes through the normal kube-scheduler. If no node has room for its resource requests, the run stays Unknown with reason ExceededNodeResources.

Tekton doesn't queue work itself; the cluster is the queue. Pending time counts against the timeout, so capacity problems can surface as timeouts.

The built-in admission controller that enforces the privileged / baseline / restricted profiles per namespace via labels.

Under restricted a privileged DinD build won't even get a Pod: the TaskRun fails at creation with a 'violates PodSecurity' message.

A TaskRun (or PipelineRun) field for Pod-level settings: nodeSelector, tolerations, affinity, securityContext, volumes and more.

It lets the same Task run on special nodes (ARM, GPUs, a dedicated CI pool) without changing the Task. A nodeSelector that only matches tainted nodes, without a toleration, leaves the Pod unschedulable.

A subset of Pod spec fields (nodeSelector, tolerations, affinity, securityContext, imagePullSecrets, env, hostAliases, dnsConfig, priorityClassName, volumes…) applied to the TaskRun's Pod.

It's how you control where and how a Task runs without editing the Task: a Task stays portable, the run carries the cluster-specific bits.

Init containers Tekton adds to the Pod: one copies the entrypoint binary into a shared volume, one writes step scripts to /tekton/scripts.

They run before any step, which is why a TaskRun sits in Pending for a moment even after the Pod is scheduled. Their lifecycle is covered with TaskRuns.

projected merges several ConfigMaps/Secrets into one directory; csi mounts a volume provided by a CSI driver.

A CSI driver such as the Secrets Store driver can fetch credentials from Vault or a cloud KMS at mount time, so they never live as Kubernetes Secrets.

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.

Verifiable information about how an artifact was produced: which builder, which build definition and inputs, which dependencies, when.

A digest tells you what an image is; provenance tells you where it came from. Policies can then reject images that were not built by your pipeline from your repo.

Deleting finished PipelineRuns and TaskRuns (and with them their Pods) so they don't accumulate in etcd.

Every run leaves several status-heavy objects behind. Without cleanup, etcd grows until it hits its quota and the API server starts refusing writes, which breaks far more than CI.

Kubernetes rules (apiGroups, resources, verbs) bound to a ServiceAccount, which decide what kubectl in a step may do.

A deploy task's kubectl apply needs get plus create or patch on its objects. Anything more is reach an attacker inherits if a step is compromised.

A Task-side flag that mounts the volume read-only for that Task's steps.

A test or scan Task that should never modify the source can declare it; writes then fail with 'Read-only file system'. ConfigMap, Secret and projected sources are read-only regardless.

A machine-readable reason on the Succeeded condition (Started, Pending, Running, Succeeded, Failed, TaskRunTimeout, TaskRunCancelled, CouldntGetTask, ExceededNodeResources, ExceededResourceQuota…) plus a human message.

The status says whether the run is done. The reason says why: a timeout and a failing test are both False but need different fixes. Some reasons, like ExceededNodeResources, keep the status Unknown because the run is waiting rather than failed.

The function reconcile(key) called for each queued object: read the spec and the current world, act, update status.

Changes are coalesced into a workqueue of keys, so ten Pod updates in a burst can mean a single reconcile. The reconciler never assumes it saw every event.

The uri, digest and entryPoint of the fetched resource, copied into TaskRun/PipelineRun status.provenance.refSource.

Even when you reference a moving branch, the run records the exact commit it used. That is how you audit drift afterwards, and what Tekton Chains puts into provenance.

Sigstore's append-only public log of signatures; with transparency.enabled, Chains uploads each one and annotates the run with the entry.

Makes signing events publicly auditable and timestamped, which keyless verification needs. Mind that public Rekor entries reveal artifact names and digests.

Fetching a Task or Pipeline definition from outside the cluster at run time, by naming a resolver and its params in taskRef/pipelineRef.

It lets teams share versioned Tasks without copying YAML into every namespace. The controller stays generic, and each source type is a pluggable resolver.

A CRD (resolution.tekton.dev/v1beta1) the Pipelines controller creates per remote ref: spec.params in, status.data (base64) and status.refSource out.

It is the contract between controller and resolver, and it is inspectable: kubectl get resolutionrequests shows what was asked, what came back, and why a resolution failed.

A controller that watches ResolutionRequests carrying its type label, fetches the requested resource and writes it back into the request's status.

Resolvers are decoupled from the Pipelines controller: built-in ones ship in the tekton-pipelines-resolvers namespace, and you can write your own with the resolver framework.

Per-resolver defaults and limits in the resolvers namespace (git-resolver-config, bundleresolver-config, hubresolver-config, cluster-resolver-config, http-resolver-config).

Defaults such as default-revision or default-org keep TaskRuns short, and fetch-timeout bounds how long a slow remote can hold up a run.

The ConfigMap with enable-git-resolver, enable-bundles-resolver, enable-hub-resolver, enable-cluster-resolver and enable-http-resolver.

Operators can switch off resolvers they don't want users to reach; a disabled resolver makes every request of that type fail.

The list of objects in a TriggerTemplate. Usually one PipelineRun, but any Tekton or Kubernetes resource the ServiceAccount may create.

One event creates every object in the list, every time. Triggers keeps no memory of earlier events, so deduplication has to come from naming or from the pipeline itself.

$(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.

$(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.

Finally tasks can consume DAG task results; if the producing task failed or was skipped, that finally task is skipped.

The skip reason is "Results were missing". The other finally tasks still run, so put a guard-free cleanup task separately.

The Results controller that watches runs in the cluster and sends each one to the Results API over gRPC, plus its logs.

It only deletes an object after it was stored and a grace period passed, so an outage of the API makes objects linger instead of losing history.

How many more times to try a failed run: set as retries on a Pipeline task, which the PipelineRun passes to the TaskRun it creates.

Each attempt is a new Pod. Retries hide flaky infrastructure or tests, but they make a real bug cost retries+1 runs before it is reported.

How many times a failed (or timed-out) pipeline task is re-executed in a fresh Pod before it counts as failed.

It hides flakiness rather than fixing it. Earlier attempts are kept in the TaskRun's `status.retriesStatus` so the history is not lost.

An explicit edge: this task starts only after the listed tasks have finished successfully.

Use it for ordering with no data flow, such as tests after a clone that only shares a workspace. Without it, tasks with no edges between them start at the same time.

Inline script text for a step, written to a file by the place-scripts init container and executed by the entrypoint.

Without a shebang Tekton runs it with #!/bin/sh and set -e. With one (#!/usr/bin/env python3) any interpreter in the image works. A step uses either script or command, not both.

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.

Binding a Secret to a workspace mounts its keys as read-only files in the Task, optionally only in the steps that declare it.

Explicit and auditable: the Task says it needs a credential, only the bound tasks get it, and nothing lands in env or in API objects.

Deliver credentials (docker config, SSH keys, .git-credentials) as files in a Secret workspace instead of environment variables.

Env vars leak through env dumps, set -x traces, child processes and every step of a stepTemplate. A step-scoped file doesn't, and kubelet refreshes it when the Secret rotates.

Pod- and container-level settings: runAsNonRoot, runAsUser, allowPrivilegeEscalation, capabilities, seccompProfile, privileged.

Some fields, like allowPrivilegeEscalation and capabilities, only exist per container, so a pod-level securityContext from podTemplate can't make every container compliant by itself.

The Kubernetes identity a TaskRun's Pod runs as; defaults to the namespace's default SA unless set.

It carries two things at once: the Secrets that credential initialization turns into git/docker config, and the RBAC token steps use against the API server. Pick it per task, not per cluster.

The Kubernetes ServiceAccount the TaskRun Pod runs as. It decides which credentials and permissions the steps get.

It is the identity of the build. Its Secrets are what Tekton's credential initialization turns into git and docker config. The Auth chapter covers it in detail.

Feature flag that makes Tekton give its injected init containers (and its own containers) a restricted-compatible securityContext.

Without it, Tekton's prepare and place-scripts containers fail the restricted profile even when your steps are clean.

A container in spec.sidecars that runs alongside the steps for the whole Task: a database, docker-in-docker, a proxy.

It shares the Pod's network, so steps reach it on localhost. Once all steps finish, the controller replaces the sidecar's image with a nop image so its container exits and the Pod can complete.

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.

A key pair generated by cosign into the signing-secrets Secret (cosign.key, cosign.password, cosign.pub) in the tekton-chains namespace.

The simplest setup, but the private key is a long-lived secret. Anyone who can read it, including a build step that somehow can, can sign arbitrary provenance.

Every skipped task is listed in `status.skippedTasks` with a reason, such as when expressions false, parent tasks skipped, results missing, run stopping, or a timeout reached.

Only a when skip is contained to its task. A task skipped for missing results or a failed run makes its dependents skip too (ParentTasksSkip). The reason tells you which case you hit.

Supply-chain Levels for Software Artifacts: a provenance predicate schema (v0.2, v1.0) and a build track of levels L0 to L3.

L1 means provenance exists, L2 means it is signed by a hosted platform, and L3 means the platform is hardened so tenants can't forge it. Chains generates and signs provenance; L3 depends on how you run the cluster.

Patching a PipelineRun's spec.status to Cancelled cancels every running TaskRun and does not run finally.

The hard stop. Cleanup in finally won't happen, so prefer the graceful modes when finally matters.

The maximum duration of the TaskRun, defaulting to 60 minutes (default-timeout-minutes in config-defaults). 0 disables it.

When it elapses the controller marks the run False/TaskRunTimeout and deletes the Pod, so nothing hangs forever. Builds that legitimately take longer need an explicit timeout.

A kubernetes.io/ssh-auth Secret with ssh-privatekey and optionally known_hosts, for git over ssh.

It becomes a Host block in ~/.ssh/config pointing at the key. Without known_hosts the server's host key is not pinned, so add it.

Timestamps set when the controller first starts the TaskRun and when it reaches a final status.

The timeout is measured from startTime. Time spent waiting for a node or pulling images counts too, so a cluster that is short on capacity can time out runs that never got to execute.

Pipelines-as-Code reports each PipelineRun back to the commit as a check run (or commit status), with a summary of its tasks.

Developers see CI where they already are, and branch protection rules can require the checks to pass before merge.

status.conditions on every run; Tekton's key condition is type Succeeded with status Unknown, True or False and a reason.

Unknown means still going (reason Pending, Running…); True and False are final (Succeeded, Failed, TaskRunTimeout, Cancelled…). Every tool, from tkn to Dashboard, reads this one field.

The list of child objects (TaskRuns, CustomRuns, child PipelineRuns) the PipelineRun created, with each one's pipelineTaskName.

It is the index from graph node to real object. The full child statuses live on the children themselves, which keeps the PipelineRun object small.

The name of the Pod created for the current attempt, normally <taskrun>-pod (or -pod-retryN on retries).

It connects the Tekton view to the Kubernetes view: kubectl describe pod, events, node placement and container logs all hang off this name.

A list holding the full status (conditions, podName, steps) of each earlier failed attempt.

The top-level status only describes the latest attempt. Without retriesStatus you'd lose the evidence of every failure that a later attempt papered over.

The list of pipeline tasks that never got a TaskRun, each with a reason: PipelineRun was stopping, When Expressions evaluated to false, Results were missing, Parent Tasks were skipped, or a timeout.

A skipped task has no TaskRun to inspect, so this list is the only place that explains why it didn't run.

One entry per step, copied from that container's state: waiting, running, or terminated with exitCode, plus Tekton's terminationReason.

terminationReason (Completed, Error, Continued, Skipped, TimeoutExceeded) shows how a step ended, which the raw exit code can't: a skipped step and a failed step both exit 1.

One entry in spec.steps: a container image plus a script or command to run in it.

Steps let each part of a job use the image that fits it (git, then golang, then crane) without building one image with every tool.

Each step's computeResources requests/limits; a namespace LimitRange supplies defaults and min/max per container.

Steps run one at a time but are regular containers, so the scheduler reserves the sum of their requests. Tekton splits a LimitRange default request across the steps that don't set one.

The exit status the entrypoint saves for each step under /tekton/steps/step-<name>/exitCode.

Later steps can read it with $(steps.step-<name>.exitCode.path) and decide what to do, and it shows up in the TaskRun's status.steps.

Each step is a container, so its stdout/stderr are that container's logs. tkn taskrun logs -f follows them step by step.

Logs live with the Pod. Once the Pod is gone (after cancel, timeout or cluster cleanup) they are gone too, unless a log store such as Tekton Results keeps them.

computeResources requests and limits on each step container.

Kubernetes sums the requests of all containers, but steps run one at a time, so per-step requests over-reserve. Older Tekton releases zeroed all but the largest step's request; current ones leave explicit requests alone.

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).

A Go duration on a single step after which the entrypoint kills its process.

A hung step fails fast and later steps are skipped, without waiting for the whole TaskRun's timeout.

A stable resource holding one reusable step (image, params, env, script) that Task steps reference with ref.

Share a git-clone or upload step across many Tasks and update it in one place. The referencing step passes params but cannot override image or script, and StepAction scripts take params through env, not direct substitution.

A container spec in the Task that every step starts from.

Put shared env, workingDir, image or resource requests in one place. A step's own fields win; env entries merge by name and requests merge key by key.

Graceful stop: running DAG tasks are allowed to finish, no new ones start, then finally runs.

Avoids leaving half-done work, such as a deploy cut off midway, while still not running the rest of the pipeline.

Once any task fails, the PipelineRun is stopping: running TaskRuns are allowed to finish, but no new ones are created.

A failure doesn't kill siblings that are already running, but branches that haven't started never will, even ones that don't depend on the failed task. Only finally tasks still run.

Where Chains puts signatures and attestations: tekton (run annotations), oci (next to the image in the registry), gcs, docdb, grafeas.

oci storage keeps the attestation with the image, which is where cosign and admission controllers look. tekton storage disappears when old runs are pruned.

An artifact the attestation is about, identified by name and digest (e.g. ghcr.io/acme/app with sha256:…).

Verification starts from the subject: the digest of what you are about to deploy must appear there. With no subject, the attestation vouches for nothing.

Mount only a subdirectory of the bound volume, set on a pipeline task's workspace binding or on the run's binding.

Lets several tasks share one PVC (one attach, one affinity assistant) while writing into separate directories, so parallel tasks don't overwrite each other's outputs.

A namespaced, reusable definition of steps, sidecars, params, results, workspaces and volumes (tekton.dev/v1).

It is the smallest unit you can run on its own and the building block of Pipelines. Each run of it is one TaskRun and one Pod.

A Task is a reusable list of steps; a TaskRun is one execution of it, with concrete params and workspaces.

Splitting what from when means a Task can be shared, versioned and reviewed, while each TaskRun records exactly what ran and how it ended.

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.

A request on the TaskRun (beta) that Tekton splits across the step containers.

The Pod then reserves what the Task needs at any one moment. Steps without requests in a namespace with a LimitRange get its default divided by the number of steps, never below the LimitRange minimum.

A reference to a Task by name in the namespace, or through a resolver (git, bundles, hub, cluster).

It lets many runs share one reviewed definition. The spec is resolved when the run starts and copied into status.taskSpec, so editing the Task later doesn't change runs already in flight. A missing Task fails the run with CouldntGetTask.

A namespaced object (tekton.dev/v1) that asks for one execution of a Task with concrete params and workspaces.

Tasks are templates; a TaskRun is what actually runs. The TaskRun controller reconciles it into exactly one Pod (per attempt) and writes the result back into its status, so the TaskRun is also the record of what happened.

PipelineRun field that overrides serviceAccountName, podTemplate, compute resources and more for one named pipeline task.

This is how you give only the deploy task the deployer SA, or only the build task arm64 nodes.

PipelineRun field that sets serviceAccountName and podTemplate for every TaskRun it creates.

The pipeline-wide default. It replaced the older top-level serviceAccountName / podTemplate fields in the v1 API.

The whole Task definition embedded directly in the TaskRun.

Good for one-off or generated runs: nothing to install first and nothing to drift. The cost is no reuse, and nothing a reviewer can approve separately from the run.

An OCI image in which each layer holds one Tekton resource, identified by the annotations dev.tekton.image.kind, dev.tekton.image.name and dev.tekton.image.apiVersion.

Packing a Pipeline and its Tasks into one image versions them together; referencing it by @sha256 digest gives you exactly the bytes you tested.

The community collection of reusable Tasks and Pipelines (tektoncd/catalog), one directory per name and version, each with a README, samples and tests.

Versions are directories, so a new version never changes an old one. The tekton.dev/pipelines.minVersion annotation says which Pipelines release a version needs.

A Kubernetes controller that observes completed TaskRuns and PipelineRuns, generates provenance for their outputs, signs it and stores it.

It adds supply-chain metadata without changing your Tasks: the build stays the same, and Chains works from the run object afterwards. It marks each run chains.tekton.dev/signed=true (or failed) when done.

Pipelines (core), Triggers, Chains, Results, Dashboard, CLI (tkn), Operator, the catalog/Hub, and Pipelines-as-Code.

Each one is more CRDs and controllers on the same API server. You can adopt Pipelines alone and add the others as you need them.

A web UI that lists PipelineRuns and TaskRuns and shows their tasks, steps and logs.

It reads the same live objects as tkn. When an object is pruned it disappears from the Dashboard too, unless logs and records are served from an external store like Results.

A Kubernetes operator that installs, configures and upgrades Tekton components from a single TektonConfig resource.

It reconciles continuously: delete a controller by hand and it comes back; bump the operator and every component rolls forward together.

A service that stores finished PipelineRuns and TaskRuns as Results and Records in a database, with an API to query them.

It separates history from live cluster state: once a run is archived it can be deleted from etcd and still be queried, audited and shown in UIs.

Where the Pipelines controller, webhook, resolvers and their ConfigMaps run.

Tekton is installed with one kubectl apply of release.yaml (or by the Operator); nothing runs outside the cluster.

A newer, event-driven pruner controller that deletes runs based on TTL after completion and per-status history limits.

Reacting to completions instead of a schedule removes the CronJob sawtooth and allows global, namespace or per-pipeline policies.

Annotations on a Secret that tell Tekton which host (or registry) the credential is for, e.g. tekton.dev/git-0: https://github.com.

The annotation is the match key. git matches on protocol + host, ssh on Host and port, docker on the registry. An https token does nothing for an ssh URL.

The stable API version for Task, TaskRun, Pipeline and PipelineRun; v1beta1 is still served and converted by the webhook.

v1 dropped PipelineResources and renamed some fields (a step's resources became computeResources). Writing v1 YAML is what makes it portable across conformant clusters.

spec.profile picks which components the operator installs: lite (Pipelines), basic (adds Triggers and Chains) or all (adds the Dashboard).

One field decides the footprint. Changing it adds or removes component CRs, and the operator handles the rest.

A small file each step's entrypoint writes on exit (/tekton/termination) that Kubernetes copies into the container status.

This is how step timing and results get from inside the Pod to the controller without any extra network calls. It is also why results must stay small: the message is capped at about 4 KB per container.

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.

A small Tekton program that becomes every step container's real command and wraps the command you wrote.

Kubernetes starts all of a Pod's containers at once. The entrypoint blocks until the previous step's /tekton/run/N/out file appears, then runs your command, then writes its own file and exit code.

status.conditions[type=Succeeded], whose status is Unknown while the run is in progress and True or False once it has finished.

Every outcome (success, failure, timeout, cancellation) is the same condition with a different status and reason. Tools such as tkn, the Dashboard and the PipelineRun controller only have to read this one field.

Deadlines on the whole PipelineRun, on its DAG tasks, and on its finally tasks. timeouts.pipeline defaults to 60 minutes.

When timeouts.pipeline expires, running TaskRuns are cancelled, unstarted tasks are skipped, and the run ends with PipelineRunTimeout. The Control flow chapter covers splitting the budget between tasks and finally.

Three budgets on a PipelineRun: the whole run, the DAG tasks (from the run's start), and the finally tasks (from when finally starts).

With only a pipeline timeout, hitting it skips finally too. Setting `tasks` reserves the rest for cleanup. tasks + finally must not exceed pipeline, and 0 means no limit.

Packages Tasks and Pipelines into an OCI image (a Tekton Bundle) and pushes it to a registry.

Bundles version and distribute pipeline definitions like container images; the bundles resolver fetches them by digest at run time.

CLI commands that build a Tekton Bundle from YAML files and push it to a registry, and list the resources inside an existing bundle.

They make bundles a normal artifact in your release process. Pushing to the same tag moves the tag, so consumers should use the printed digest.

The Tekton command-line client: start, list, describe, follow logs of, cancel and delete Tekton objects.

It is a convenience layer over the Kubernetes API. Everything it does is reading or writing the same CRDs kubectl sees, plus following Pod container logs in DAG order.

Groups interceptors, bindings and a template into one unit. It can be written inline in an EventListener or as its own CRD.

As standalone CRDs, Triggers can live in team namespaces and be picked up by a shared listener through selectors. Each one can set its own serviceAccountName for the objects it creates.

A namespaced list of params whose values are expressions over the event, like $(body.head_commit.id).

It separates reading the payload from the PipelineRun shape, so the same template can serve GitHub, GitLab or a cron job as long as each one has its own binding.

Declares params (optionally with defaults) and resourcetemplates, the Kubernetes objects to create for each event.

It is the blueprint for a run. The listener substitutes $(tt.params.x) into it and creates the result with its own ServiceAccount, so that account needs RBAC to create PipelineRuns.

A Pipelines feature that verifies a signature on remotely resolved Tasks and Pipelines before running them.

Pinning tells you which bytes you got; a signature tells you who published them. Together they close the gap between “the file I resolved” and “the file my release team approved”.

Naming conventions for Task results that tell Chains which artifacts a run produced.

Chains does not inspect what your steps push. If results are misnamed or the digest is malformed, the build still succeeds but the attestation has no subject.

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.

Resolving the image digest, fetching the attestation for that digest, checking the signature against a key or identity, and checking the subject and predicate.

Flipping one bit of the image changes its digest, and editing the provenance breaks the signature. Neither can be hidden, as long as the verifier pins the right key or identity.

A namespaced CRD mapping source patterns (regexes over the resource's source URI) to authorities: public keys from inline data, a Secret or KMS, with mode enforce or warn.

enforce fails the run on a bad or missing signature; warn runs it but sets TrustedResourcesVerified=False. Sources that match no policy fall back to the no-match feature flag (ignore, warn or fail).

A PVC spec the controller instantiates once per PipelineRun (or TaskRun), with an ownerReference to it.

Each run gets a clean, private volume, and deleting or pruning the run garbage-collects the PVC. It is not deleted when the run finishes, so pruning old runs matters for storage quota.

The older style of custom interceptor: a plain Kubernetes Service that receives the raw HTTP event and returns 200 to continue.

Its response body and headers replace the event's, so it can rewrite payloads. It doesn't use the InterceptorRequest protocol, and new interceptors should usually be ClusterInterceptors instead.

A shared secret configured both in the Git provider's webhook settings and in a Kubernetes Secret that the interceptor reads via secretRef.

The two copies have to match. After a rotation that misses one side, every event is dropped silently while the provider still sees a 202.

Mounted volumes: workspaces under /workspace, /tekton/results, /tekton/home, and any volumes you mount; not env vars, processes, or the image filesystem.

Each step is a separate container, so the only way to hand something on is to write it to a path both steps mount. Anything else is gone when the step exits.

A guard on a pipeline task: if any expression in its `when` list is false, the task is skipped instead of run.

It replaces the removed Conditions CRD. Guards are evaluated by the controller, so a skipped task never creates a Pod.

When a task is skipped because its when is false, tasks that merely runAfter it still run.

Tekton used to cascade the skip; now the guard is scoped to the task. To skip a whole branch, repeat the guard on each task, or make dependents consume the guarded task's results.

The directory a step's command starts in.

A cd in one step does not carry to the next, so set workingDir on each step, or once in stepTemplate.

A named slot for a filesystem that a Task declares and a TaskRun or PipelineRun fills with a real volume.

It keeps Tasks portable: the Task only says it needs a directory called source; whether that's an emptyDir, a PVC or a Secret is decided at run time.