DOCSEARCHbyAlgolia
Submit Docs

Tekton Pipelines

repository·main·Indexed 11 days ago

https://github.com/tektoncd/pipeline

Kubernetes-native resources for defining and executing CI/CD pipelines using containers and Kubernetes-style abstractions. Core entities include Task, TaskRun, Pipeline, and PipelineRun. Features include an entrypoint binary for managing step execution and sidecar readiness, a Resolver framework for custom storage backends, and workspace isolation using volumeClaimTemplates.

Tokens
180.7K
Snippets
376
Records
652
Agent score
93%

What's inside Tekton

  1. Configure a TaskRun

    main

    A TaskRun is the resource used to execute a Task. It supports several configuration fields to control execution behavior.

    Required Fields

    • apiVersion: The API version (e.g., tekton.dev/v1beta1 or tekton.dev/v1).
    • kind: Must be TaskRun.
    • metadata: Unique identifier for the TaskRun (e.g., name).
    • spec: The configuration block containing:
      • taskRef or taskSpec: Defines which Task to execute.

    Optional Fields

    • serviceAccountName: Custom credentials for execution.
    • params: Execution parameters for the Task.
    • timeout: Duration before the TaskRun fails (Go ParseDuration format).
    • podTemplate: A Pod template to customize the execution environment.
    • workspaces: Physical volumes to map to Task workspaces.
    • debug: Breakpoints and debugging configuration.
    • stepSpecs / sidecarSpecs: Overrides for specific named Steps or Sidecars.
    • managedBy: The controller responsible for the lifecycle.

  2. Methods for accessing Tekton execution logs

    main

    There are several ways to access and view execution logs for TaskRuns and PipelineRuns:

    1. kubectl: Directly interact with the underlying Kubernetes Pods.
    2. tkn CLI: Use the Tekton CLI tool for a streamlined experience.
    3. Tekton Dashboard: Use the web-based UI for visual log inspection.
    4. External Services: Configure external logging stacks (e.g., ElasticSearch, Beats, and Kibana) to consume and display logs for long-term storage and analysis.

  3. What is a CustomRun and how does it work?

    main

    A CustomRun (specifically v1beta1.CustomRun) is a resource used to instantiate and execute a Custom Task.

    Unlike standard Tekton TaskRuns, Custom Tasks are implemented by a custom task controller running on your Kubernetes cluster. This allows for execution behaviors that are independent of the standard Tekton implementation.

    Important Requirement: For a CustomRun to execute, a custom task controller must be running on the cluster that is specifically configured to watch and update CustomRuns of that specific type. If no such controller is present, the CustomRun will remain in a state with no .status value and no action will be taken.

  4. What is Hermetic Execution Mode?

    main

    Hermetic execution mode is an experimental alpha feature designed to increase build reliability and consistency by ensuring builds are self-contained. When enabled, all TaskRun steps are executed without network access, preventing them from fetching dependencies at runtime.

    Important Notes:

    • This mode does NOT apply to sidecar containers.
    • It is currently an alpha experimental feature.
    • It is intended to prevent builds from depending on anything outside of the provided build environment.

  5. What is a Matrix and how to enable it

    main

    A Matrix is a feature used to fan out Tasks in a Pipeline by generating multiple combinations of parameters. This allows a single PipelineTask to run multiple times with different inputs (e.g., testing across multiple operating systems and browsers simultaneously).

    :seedling: Matrix is a beta feature.

    To use Matrix in a PipelineTask, you must set the enable-api-fields feature flag to "beta" in your Tekton configuration.

  6. What is a Tekton Resolver?

    main

    A Resolver is a program that runs in a Kubernetes cluster alongside Tekton Pipelines to handle requests for Tasks and Pipelines from remote locations.

    Instead of Tekton Pipelines having built-in support for every possible storage system, it uses the Resolver pattern. When a PipelineRun requires a resource stored in a remote location (like a Git repository or a cloud bucket), a Resolver is responsible for fetching that YAML and returning it to Tekton Pipelines. This allows developers to extend Tekton to support new version control systems or cloud storage providers without modifying the core Tekton Pipelines code.

  7. Overview of Tekton Pipelines v1 Resources

    main

    Tekton Pipelines uses several core resource types to define and execute container-based workflows. These are categorized into Authoring-time Primitives (used to define the workflow) and Runtime Primitives (used to execute the workflow).

    Authoring-time Primitives

    These resources define the structure of your work but do not execute anything on their own:

    • Task: A collection of Steps arranged in a sequential order of execution.
    • Pipeline: A collection of Tasks arranged in a specific order of execution.

    Runtime Primitives

    These resources represent actual executions of your defined workflows. Tekton implementations are required to provide CRUD APIs for these:

    • TaskRun: An instantiation of a single execution of a Task. It can describe the steps of the Task directly.
    • PipelineRun: An instantiation of a single execution of a Pipeline. It can describe the spec of the Pipeline directly.

  8. What is a PipelineRun

    main

    A PipelineRun is the resource used to instantiate and execute a Pipeline on a Kubernetes cluster. While a Pipeline defines the desired order of execution for one or more Tasks, the PipelineRun is the actual execution instance.

    Key behaviors:

    • Task Execution: It executes the Tasks in the order specified by the Pipeline until all tasks succeed or a failure occurs.
    • Automatic TaskRuns: A PipelineRun automatically creates a corresponding TaskRun for every Task defined in the Pipeline.
    • Observability: The Status field tracks the current state of the execution and contains the status of every individual TaskRun, as well as the full PipelineSpec used for the instantiation to ensure auditability.

  9. What is a TaskRun

    main
    A TaskRun is the execution instance of a Task. While a Task defines the blueprint (the sequence of Steps and container images to run), the TaskRun is the actual on-cluster instantiation that executes those steps in order. The execution continues until all steps complete successfully or a failure occurs.

  10. What is a Tekton Task?

    main

    A Task is a collection of Steps defined and arranged in a specific execution order as part of a continuous integration flow. When executed, a Task runs as a Pod on your Kubernetes cluster.

    Tasks are scoped to a specific namespace. While you can access them within that namespace, it is recommended to use a cluster resolver to access Tasks across the entire cluster. Note that ClusterTasks are deprecated in favor of using the cluster resolver.

  11. What is a Tekton Pipeline

    main
    A Pipeline is a collection of Tasks arranged in a specific execution order to form a continuous integration flow. Each Task within a Pipeline executes as a Pod on your Kubernetes cluster. Pipelines allow you to define execution conditions, parameters, and workspaces to suit your business logic.

  12. What is a StepAction and how does it relate to Steps?

    main

    A StepAction is a reusable and scriptable unit of work performed by a Step.

    It is important to distinguish between the two:

    • Step: Not reusable. It is in-lined within a Task definition. A Step acts as the actionable component that performs work directly or references a StepAction.
    • StepAction: Reusable and referenceable. It cannot be run standalone (unlike a TaskRun or PipelineRun); it must be referenced by a Step.

    Think of a Step as the orchestrator that provides the necessary context and orchestration required for a StepAction to execute.