tekton Pipelines in Pipelines Pipelines in Pipelines weight 406

Answer:
<!--
---
linkTitle: "Pipelines in Pipelines"
weight: 406
---
-->

# Pipelines in Pipelines

- [Overview](#overview)
- [Specifying `pipelineRef` in `Tasks`](#specifying-pipelineref-in-pipelinetasks)
- [Specifying `pipelineSpec` in `Tasks`](#specifying-pipelinespec-in-pipelinetasks)
- [Specifying `Parameters`](#specifying-parameters)

## Overview

A mechanism to define and execute Pipelines in Pipelines, alongside Tasks and Custom Tasks, for a more in-depth background and inspiration, refer to the proposal [TEP-0056](https://github.com/tektoncd/community/blob/main/teps/0056-pipelines-in-pipelines.md "Proposal").

> :seedling: **Pipelines in Pipelines is an  [alpha](additional-configs.md#alpha-features) feature.**
> The `enable-api-fields` feature flag must be set to `"alpha"` to specify `pipelineRef` or `pipelineSpec` in a `pipelineTask`.
> This feature is in Preview Only mode and not yet supported/implemented.

## Specifying `pipelineRef` in `pipelineTasks`

Defining Pipelines in Pipelines at authoring time, by either specifying `PipelineRef` or `PipelineSpec` fields to a `PipelineTask` alongside `TaskRef` and `TaskSpec`.

For example, a Pipeline named security-scans which is run within a Pipeline named clone-scan-notify where the PipelineRef is used:

```
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: security-scans
spec:
  tasks:
    - name: scorecards
      taskRef:
        name: scorecards
    - name: codeql
      taskRef:
        name: codeql
---
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: clone-scan-notify
spec:
  tasks:
    - name: git-clone
      taskRef:
        name: git-clone
    - name: security-scans
      pipelineRef:
        name: security-scans
    - name: notification
      taskRef:
        name: notification
```

## Specifying `pipelineSpec` in `pipelineTasks`

The `pipelineRef` [example](#specifying-pipelineref-in-pipelinetasks) can be modified to use PipelineSpec instead of PipelineRef to instead embed the Pipeline specification:
```
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: clone-scan-notify
spec:
  tasks:
    - name: git-clone
      taskRef:
        name: git-clone
    - name: security-scans
      pipelineSpec:
        tasks:
          - name: scorecards
            taskRef:
              name: scorecards
          - name: codeql
            taskRef:
              name: codeql
    - name: notification
      taskRef:
        name: notification
```

## Specifying `Parameters`

Pipelines in Pipelines consume Parameters in the same way as Tasks in Pipelines
```
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: clone-scan-notify
spec:
  params:
    - name: repo
      value: $(params.repo)
  tasks:
    - name: git-clone
      params:
        - name: repo
          value: $(params.repo)
      taskRef:
        name: git-clone
    - name: security-scans
      params:
        - name: repo
          value: $(params.repo)
      pipelineRef:
        name: security-scans
    - name: notification
      taskRef:
        name: notification
```

linkTitle   Pipelines in Pipelines  weight  406            Pipelines in Pipelines     Overview   overview     Specifying  pipelineRef  in  Tasks    specifying pipelineref in pipelinetasks     Specifying  pipelineSpec  in  Tasks    specifying pipelinespec in pipelinetasks     Specifying  Parameters    specifying parameters      Overview  A mechanism to define and execute Pipelines in Pipelines  alongside Tasks and Custom Tasks  for a more in depth background and inspiration  refer to the proposal  TEP 0056  https   github com tektoncd community blob main teps 0056 pipelines in pipelines md  Proposal        seedling    Pipelines in Pipelines is an   alpha  additional configs md alpha features  feature      The  enable api fields  feature flag must be set to   alpha   to specify  pipelineRef  or  pipelineSpec  in a  pipelineTask     This feature is in Preview Only mode and not yet supported implemented      Specifying  pipelineRef  in  pipelineTasks   Defining Pipelines in Pipelines at authoring time  by either specifying  PipelineRef  or  PipelineSpec  fields to a  PipelineTask  alongside  TaskRef  and  TaskSpec    For example  a Pipeline named security scans which is run within a Pipeline named clone scan notify where the PipelineRef is used       apiVersion  tekton dev v1 kind  Pipeline metadata    name  security scans spec    tasks        name  scorecards       taskRef          name  scorecards       name  codeql       taskRef          name  codeql     apiVersion  tekton dev v1 kind  Pipeline metadata    name  clone scan notify spec    tasks        name  git clone       taskRef          name  git clone       name  security scans       pipelineRef          name  security scans       name  notification       taskRef          name  notification         Specifying  pipelineSpec  in  pipelineTasks   The  pipelineRef   example   specifying pipelineref in pipelinetasks  can be modified to use PipelineSpec instead of PipelineRef to instead embed the Pipeline specification      apiVersion  tekton dev v1 kind  Pipeline metadata    name  clone scan notify spec    tasks        name  git clone       taskRef          name  git clone       name  security scans       pipelineSpec          tasks              name  scorecards             taskRef                name  scorecards             name  codeql             taskRef                name  codeql       name  notification       taskRef          name  notification         Specifying  Parameters   Pipelines in Pipelines consume Parameters in the same way as Tasks in Pipelines     apiVersion  tekton dev v1 kind  Pipeline metadata    name  clone scan notify spec    params        name  repo       value    params repo    tasks        name  git clone       params            name  repo           value    params repo              taskRef          name  git clone       name  security scans       params            name  repo           value    params repo        pipelineRef          name  security scans       name  notification       taskRef          name  notification


Answer:
<!--
---
linkTitle: "CustomRuns"
weight: 206
---
-->

# CustomRuns

- [Overview](#overview)
- [Configuring a `CustomRun`](#configuring-a-customrun)
  - [Specifying the target Custom Task](#specifying-the-target-custom-task)
  - [Cancellation](#cancellation)
  - [Specifying `Timeout`](#specifying-timeout)
  - [Specifying `Retries`](#specifying-retries)
  - [Specifying Parameters](#specifying-parameters)
  - [Specifying Workspaces](#specifying-workspaces)
  - [Specifying Service Account](#specifying-a-serviceaccount)
- [Monitoring execution status](#monitoring-execution-status)
  - [Status Reporting](#status-reporting)
  - [Monitoring `Results`](#monitoring-results)
- [Code examples](#code-examples)
  - [Example `CustomRun` with a referenced custom task](#example-customrun-with-a-referenced-custom-task)
  - [Example `CustomRun` with an unnamed custom task](#example-customrun-with-an-unnamed-custom-task)
  - [Example of specifying parameters](#example-of-specifying-parameters)

# Overview

*`v1beta1.CustomRun` has replaced `v1alpha1.Run` for executing `Custom Tasks`. Please refer to the [migration doc](migrating-v1alpha1.Run-to-v1beta1.CustomRun.md) for details
on updating `v1alpha1.Run` to `v1beta1.CustomRun` before upgrading to a release that does not support `v1alpha1.Run`.*

A `CustomRun` allows you to instantiate and execute a [Custom
Task](https://github.com/tektoncd/community/blob/main/teps/0002-custom-tasks.md),
which can be implemented by a custom task controller running on-cluster. Custom
Tasks can implement behavior that's independent of how Tekton TaskRun is implemented.

In order for a `CustomRun` to actually execute, there must be a custom task
controller running on the cluster that is responsible for watching and updating
`CustomRun`s which reference their type. If no such controller is running, `CustomRun`s
will have no `.status` value and no further action will be taken.

## Configuring a `CustomRun`

A `CustomRun` definition supports the following fields:

- Required:
  - [`apiVersion`][kubernetes-overview] - Specifies the API version. Currently,only
    `tekton.dev/v1beta1` is supported.
  - [`kind`][kubernetes-overview] - Identifies this resource object as a `CustomRun` object.
  - [`metadata`][kubernetes-overview] - Specifies the metadata that uniquely identifies the
    `CustomRun`, such as a `name`.
  - [`spec`][kubernetes-overview] - Specifies the configuration for the `CustomRun`.
    - [`customRef`](#1-specifying-the-target-custom-task-with-customref) - Specifies the type and
      (optionally) name of the custom task type to execute.
    - [`customSpec`](#2-specifying-the-target-custom-task-by-embedding-its-spec) - Embed the custom task resource spec
      directly in a `CustomRun`.
- Optional:
  - [`timeout`](#specifying-timeout) - specifies the maximum duration of a single execution
    of a `CustomRun`.
  - [`retries`](#specifying-retries) - specifies the number of retries to execute upon `CustomRun`failure.
  - [`params`](#specifying-parameters) - Specifies the desired execution
    parameters for the custom task.
  - [`serviceAccountName`](#specifying-a-serviceaccount) - Specifies a `ServiceAccount`
    object for executing the `CustomRun`.
  - [`workspaces`](#specifying-workspaces) - Specifies the physical volumes to use for the
    [`Workspaces`](workspaces.md) required by a custom task.

[kubernetes-overview]:
  https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/#required-fields

### Specifying the target Custom Task

A custom task resource's `CustomSpec` may be directly embedded in the `CustomRun` or it may
be referred to by a `CustomRef`. But, not both at the same time.

1. [Specifying the target Custom Task with customRef](#specifying-the-target-custom-task-with-customref)
   Referring a custom task (i.e. `CustomRef` ) promotes reuse of custom task definitions.

2. [Specifying the target Custom Task by embedding its spec](#specifying-the-target-custom-task-by-embedding-its-customspec)
   Embedding a custom task (i.e. `CustomSpec` ) helps in avoiding name collisions with other users within the same namespace.
   Additionally, in a pipeline with multiple embedded custom tasks, the details of entire pipeline can be fetched in a
   single API request.

#### Specifying the target Custom Task with customRef

To specify the custom task type you want to execute in your `CustomRun`, use the
`customRef` field as shown below:

```yaml
apiVersion: tekton.dev/v1beta1
kind: CustomRun
metadata:
  name: my-example-run
spec:
  customRef:
    apiVersion: example.dev/v1beta1
    kind: MyCustomKind
  params:
  - name: duration
    value: 10s
```

When this `CustomRun` is created, the Custom Task controller responsible for
reconciling objects of kind "MyCustomKind" in the "example.dev/v1beta1" api group
will execute it based on the input params.

You can also specify the `name` and optional `namespace` (default is `default`)
of a custom task resource object previously defined in the cluster.

```yaml
apiVersion: tekton.dev/v1beta1
kind: CustomRun
metadata:
  name: my-example-run
spec:
  customRef:
    apiVersion: example.dev/v1beta1
    kind: Example
    name: an-existing-example-task
```

If the `customRef` specifies a name, the custom task controller should look up the
`Example` resource with that name, and use that object to configure the
execution.

If the `customRef` does not specify a name, the custom task controller might support
some default behavior for executing unnamed tasks.

In either case, if the named resource cannot be found, or if unnamed tasks are
not supported, the custom task controller should update the `CustomRun`'s status to
indicate the error.

####  Specifying the target Custom Task by embedding its customSpec

To specify the custom task spec, it can be embedded directly into a
`CustomRun`'s spec as shown below:

```yaml
apiVersion: tekton.dev/v1beta1
kind: CustomRun
metadata:
  name: embedded-run
spec:
  customSpec:
    apiVersion: example.dev/v1beta1
    kind: Example
    spec:
      field1: value1
      field2: value2
```

When this `CustomRun` is created, the custom task controller responsible for
reconciling objects of kind `Example` in the `example.dev` api group will
execute it.

#### Developer guide for custom controllers supporting `customSpec`.

1. A custom controller may or may not support a `Spec`. In cases where it is
   not supported the custom controller should respond with proper validation
   error.

2. Validation of the fields of the custom task is delegated to the custom
   task controller. It is recommended to implement validations as asynchronous
   (i.e. at reconcile time), rather than part of the webhook. Using a webhook
   for validation is problematic because, it is not possible to filter custom
   task resource objects before validation step, as a result each custom task
   resource has to undergo validation by all the installed custom task
   controllers.

3. A custom task may have an empty spec, but cannot have an empty
   `ApiVersion` and `Kind`. Custom task controllers should handle
   an empty spec, either with a default behaviour, in a case no default
   behaviour is supported then, appropriate validation error should be
   updated to the `CustomRun`'s status.

### Cancellation

The custom task is responsible for implementing `cancellation` to support pipelineRun level `timeouts` and `cancellation`. If the Custom Task implementor does not support cancellation via `.spec.status`, `Pipeline` **can not** timeout within the specified interval/duration and **can not** be cancelled as expected upon request.

Pipeline Controller sets the `spec.Status` and `spec.StatusMessage` to signal `CustomRuns` about the `Cancellation`, while `CustomRun` controller updates its `status.conditions` as following once noticed the change on `spec.Status`.

```yaml
status
  conditions:
  - type: Succeeded
    status: False
    reason: CustomRunCancelled
```

### Specifying `Timeout`

A custom task specification can be created with `Timeout` as follows:

```yaml
apiVersion: tekton.dev/v1beta1
kind: CustomRun
metadata:
  generateName: simpleexample
spec:
  timeout: 10s # set timeouts here.
  params:
    - name: searching
      value: the purpose of my existence
  customRef:
    apiVersion: custom.tekton.dev/v1alpha1
    kind: Example
    name: exampleName
```

Supporting timeouts is optional but recommended.

#### Developer guide for custom controllers supporting `Timeout`

1. Tekton controllers will never directly update the status of the `CustomRun`,
   it is the responsibility of the custom task controller to support timeout.
   If timeout is not supported, it's the responsibility of the custom task
   controller to reject `CustomRun`s that specify a timeout value.
2. When `CustomRun.Spec.Status` is updated to `RunCancelled`, the custom task controller
   MUST cancel the `CustomRun`. Otherwise, pipeline-level `Timeout` and
   `Cancellation` won't work for the Custom Task.
3. A Custom Task controller can watch for this status update
   (i.e. `CustomRun.Spec.Status == RunCancelled`) and or `CustomRun.HasTimedOut()`
   and take any corresponding actions (i.e. a clean up e.g., cancel a cloud build,
   stop the waiting timer, tear down the approval listener).
4. Once resources or timers are cleaned up, while it is **REQUIRED** to set a
   `conditions` on the `CustomRun`'s `status` of `Succeeded/False` with an optional
   `Reason` of `CustomRunTimedOut`.
5. `Timeout` is specified for each `retry attempt` instead of all `retries`.

### Specifying `Retries`

A custom task specification can be created with `Retries` as follows:

```yaml
apiVersion: tekton.dev/v1beta1
kind: CustomRun
metadata:
  generateName: simpleexample
spec:
  retries: 3 # set retries
  params:
    - name: searching
      value: the purpose of my existence
  customRef:
    apiVersion: custom.tekton.dev/v1alpha1
    kind: Example
    name: exampleName
```

Supporting retries is optional but recommended.

#### Developer guide for custom controllers supporting `retries`

1. Tekton controller only depends on `ConditionSucceeded` to determine the
   termination status of a `CustomRun`, therefore Custom task implementors
   MUST NOT set `ConditionSucceeded` to `False` until all retries are exhausted.
2. Those custom tasks who do not wish to support retry, can simply ignore it.
3. It is recommended, that custom task should update the field `RetriesStatus`
   of a `CustomRun` on each retry performed by the custom task.
4. Tekton controller does not validate that number of entries in `RetriesStatus`
   is same as specified value of retries count.

### Specifying `Parameters`

If a custom task supports [`parameters`](tasks.md#parameters), you can use the
`params` field in the `CustomRun` to specify their values:

```yaml
spec:
  params:
    - name: my-param
      value: chicken
```

If the custom task controller knows how to interpret the parameter value, it
will do so. It might enforce that some parameter values must be specified, or
reject unknown parameter values.

### Specifying workspaces

If the custom task supports it, you can provide [`Workspaces`](workspaces.md) to share data with the custom task .

```yaml
spec:
  workspaces:
    - name: my-workspace
      emptyDir: {}
```

Consult the documentation of the custom task that you are using to determine whether it supports workspaces and how to name them.

### Specifying a ServiceAccount

If the custom task supports it, you can execute the `CustomRun` with a specific set of credentials by
specifying a `ServiceAccount` object name in the `serviceAccountName` field in your `CustomRun`
definition. If you do not explicitly specify this, the `CustomRun` executes with the service account
specified in the `configmap-defaults` `ConfigMap`. If this default is not specified, `CustomRuns`
will execute with the [`default` service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server)
set for the target [`namespace`](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/).

```yaml
spec:
  serviceAccountName: my-account
```

Consult the documentation of the custom task that you are using to determine whether it supports a service account name.

## Monitoring execution status

As your `CustomRun` executes, its `status` field accumulates information on the
execution of the `CustomRun`. This information includes the current state of the
`CustomRun`, start and completion times, and any output `results` reported by
the custom task controller.

### Status Reporting

When the `CustomRun<Example>` is validated and created, the Custom Task controller will be notified and is expected to begin doing some operation. When the operation begins, the controller **MUST** update the `CustomRun`'s `.status.conditions` to report that it's ongoing:

```yaml
status
  conditions:
  - type: Succeeded
    status: Unknown
```

When the operation completes, if it was successful, the condition **MUST** report `status: True`, and optionally a brief `reason` and human-readable `message`:

```yaml
status
  conditions:
  - type: Succeeded
    status: True
    reason: ExampleComplete # optional
    message: Yay, good times # optional
```

If the operation was _unsuccessful_, the condition **MUST** report `status: False`, and optionally a `reason` and human-readable `message`:

```yaml
status
  conditions:
  - type: Succeeded
    status: False
    reason: ExampleFailed # optional
    message: Oh no bad times # optional
```

If the `CustomRun` was _cancelled_, the condition **MUST** report `status: False`, `reason: CustomRunCancelled`, and optionally a human-readable `message`:

```yaml
status
  conditions:
  - type: Succeeded
    status: False
    reason: CustomRunCancelled
    message: Oh it's cancelled # optional
```

The following tables shows the overall status of a `CustomRun`:

`status`|Description
:-------|:-----------
<unset>|The custom task controller has not taken any action on the `CustomRun`.
Unknown|The custom task controller has started execution and the `CustomRun` is ongoing.
True|The `CustomRun` completed successfully.
False|The `CustomRun` completed unsuccessfully, and all retries were exhausted.

The `CustomRun` type's `.status` will also allow controllers to report other fields, such as `startTime`, `completionTime`, `results` (see below), and arbitrary context-dependent fields the Custom Task author wants to report. A fully-specified `CustomRun` status might look like:

```
status
  conditions:
  - type: Succeeded
    status: True
    reason: ExampleComplete
    message: Yay, good times
  completionTime: "2020-06-18T11:55:01Z"
  startTime: "2020-06-18T11:55:01Z"
  results:
  - name: first-name
    value: Bob
  - name: last-name
    value: Smith
  arbitraryField: hello world
  arbitraryStructuredField:
    listOfThings: ["a", "b", "c"]
```

### Monitoring `Results`

After the `CustomRun` completes, the custom task controller can report output
values in the `results` field:

```
results:
- name: my-result
  value: chicken
```

## Code examples

To better understand `CustomRuns`, study the following code examples:

- [Example `CustomRun` with a referenced custom task](#example-customrun-with-a-referenced-custom-task)
- [Example `CustomRun` with an unnamed custom task](#example-customrun-with-an-unnamed-custom-task)
- [Example of specifying parameters](#example-of-specifying-parameters)

### Example `CustomRun` with a referenced custom task

In this example, a `CustomRun` named `my-example-run` invokes a custom task of the `v1alpha1`
version of the `Example` kind in the `example.dev` API group, with the name
`my-example-task`.

In this case the custom task controller is expected to look up the `Example`
resource named `my-example-task` and to use that configuration to configure the
execution of the `CustomRun`.

```yaml
apiVersion: tekton.dev/v1beta1
kind: CustomRun
metadata:
  name: my-example-run
spec:
  customRef:
    apiVersion: example.dev/v1alpha1
    kind: Example
    name: my-example-task
```

### Example `CustomRun` with an unnamed custom task

In this example, a `CustomRun` named `my-example-run` invokes a custom task of the `v1alpha1`
version of the `Example` kind in the `example.dev` API group, without a specified name.

In this case the custom task controller is expected to provide some default
behavior when the referenced task is unnamed.

```yaml
apiVersion: tekton.dev/v1beta1
kind: CustomRun
metadata:
  name: my-example-run
spec:
  customRef:
    apiVersion: example.dev/v1alpha1
    kind: Example
```

### Example of specifying parameters

In this example, a `CustomRun` named `my-example-run` invokes a custom task, and
specifies some parameter values to further configure the execution's behavior.

In this case the custom task controller is expected to validate and interpret
these parameter values and use them to configure the `CustomRun`'s execution.

```yaml
apiVersion: tekton.dev/v1alpha1
kind: CustomRun
metadata:
  name: my-example-run
spec:
  customRef:
    apiVersion: example.dev/v1alpha1
    kind: Example
    name: my-example-task
  params:
    - name: my-first-param
      value: i'm number one
    - name: my-second-param
      value: close second
```

linkTitle   CustomRuns  weight  206            CustomRuns     Overview   overview     Configuring a  CustomRun    configuring a customrun       Specifying the target Custom Task   specifying the target custom task       Cancellation   cancellation       Specifying  Timeout    specifying timeout       Specifying  Retries    specifying retries       Specifying Parameters   specifying parameters       Specifying Workspaces   specifying workspaces       Specifying Service Account   specifying a serviceaccount     Monitoring execution status   monitoring execution status       Status Reporting   status reporting       Monitoring  Results    monitoring results     Code examples   code examples       Example  CustomRun  with a referenced custom task   example customrun with a referenced custom task       Example  CustomRun  with an unnamed custom task   example customrun with an unnamed custom task       Example of specifying parameters   example of specifying parameters     Overview    v1beta1 CustomRun  has replaced  v1alpha1 Run  for executing  Custom Tasks   Please refer to the  migration doc  migrating v1alpha1 Run to v1beta1 CustomRun md  for details on updating  v1alpha1 Run  to  v1beta1 CustomRun  before upgrading to a release that does not support  v1alpha1 Run     A  CustomRun  allows you to instantiate and execute a  Custom Task  https   github com tektoncd community blob main teps 0002 custom tasks md   which can be implemented by a custom task controller running on cluster  Custom Tasks can implement behavior that s independent of how Tekton TaskRun is implemented   In order for a  CustomRun  to actually execute  there must be a custom task controller running on the cluster that is responsible for watching and updating  CustomRun s which reference their type  If no such controller is running   CustomRun s will have no   status  value and no further action will be taken      Configuring a  CustomRun   A  CustomRun  definition supports the following fields     Required        apiVersion   kubernetes overview    Specifies the API version  Currently only      tekton dev v1beta1  is supported        kind   kubernetes overview    Identifies this resource object as a  CustomRun  object        metadata   kubernetes overview    Specifies the metadata that uniquely identifies the      CustomRun   such as a  name         spec   kubernetes overview    Specifies the configuration for the  CustomRun           customRef    1 specifying the target custom task with customref    Specifies the type and        optionally  name of the custom task type to execute          customSpec    2 specifying the target custom task by embedding its spec    Embed the custom task resource spec       directly in a  CustomRun     Optional        timeout    specifying timeout    specifies the maximum duration of a single execution     of a  CustomRun         retries    specifying retries    specifies the number of retries to execute upon  CustomRun failure        params    specifying parameters    Specifies the desired execution     parameters for the custom task        serviceAccountName    specifying a serviceaccount    Specifies a  ServiceAccount      object for executing the  CustomRun         workspaces    specifying workspaces    Specifies the physical volumes to use for the       Workspaces   workspaces md  required by a custom task    kubernetes overview     https   kubernetes io docs concepts overview working with objects kubernetes objects  required fields      Specifying the target Custom Task  A custom task resource s  CustomSpec  may be directly embedded in the  CustomRun  or it may be referred to by a  CustomRef   But  not both at the same time   1   Specifying the target Custom Task with customRef   specifying the target custom task with customref     Referring a custom task  i e   CustomRef    promotes reuse of custom task definitions   2   Specifying the target Custom Task by embedding its spec   specifying the target custom task by embedding its customspec     Embedding a custom task  i e   CustomSpec    helps in avoiding name collisions with other users within the same namespace     Additionally  in a pipeline with multiple embedded custom tasks  the details of entire pipeline can be fetched in a    single API request        Specifying the target Custom Task with customRef  To specify the custom task type you want to execute in your  CustomRun   use the  customRef  field as shown below      yaml apiVersion  tekton dev v1beta1 kind  CustomRun metadata    name  my example run spec    customRef      apiVersion  example dev v1beta1     kind  MyCustomKind   params      name  duration     value  10s      When this  CustomRun  is created  the Custom Task controller responsible for reconciling objects of kind  MyCustomKind  in the  example dev v1beta1  api group will execute it based on the input params   You can also specify the  name  and optional  namespace   default is  default   of a custom task resource object previously defined in the cluster      yaml apiVersion  tekton dev v1beta1 kind  CustomRun metadata    name  my example run spec    customRef      apiVersion  example dev v1beta1     kind  Example     name  an existing example task      If the  customRef  specifies a name  the custom task controller should look up the  Example  resource with that name  and use that object to configure the execution   If the  customRef  does not specify a name  the custom task controller might support some default behavior for executing unnamed tasks   In either case  if the named resource cannot be found  or if unnamed tasks are not supported  the custom task controller should update the  CustomRun  s status to indicate the error         Specifying the target Custom Task by embedding its customSpec  To specify the custom task spec  it can be embedded directly into a  CustomRun  s spec as shown below      yaml apiVersion  tekton dev v1beta1 kind  CustomRun metadata    name  embedded run spec    customSpec      apiVersion  example dev v1beta1     kind  Example     spec        field1  value1       field2  value2      When this  CustomRun  is created  the custom task controller responsible for reconciling objects of kind  Example  in the  example dev  api group will execute it        Developer guide for custom controllers supporting  customSpec    1  A custom controller may or may not support a  Spec   In cases where it is    not supported the custom controller should respond with proper validation    error   2  Validation of the fields of the custom task is delegated to the custom    task controller  It is recommended to implement validations as asynchronous     i e  at reconcile time   rather than part of the webhook  Using a webhook    for validation is problematic because  it is not possible to filter custom    task resource objects before validation step  as a result each custom task    resource has to undergo validation by all the installed custom task    controllers   3  A custom task may have an empty spec  but cannot have an empty     ApiVersion  and  Kind   Custom task controllers should handle    an empty spec  either with a default behaviour  in a case no default    behaviour is supported then  appropriate validation error should be    updated to the  CustomRun  s status       Cancellation  The custom task is responsible for implementing  cancellation  to support pipelineRun level  timeouts  and  cancellation   If the Custom Task implementor does not support cancellation via   spec status    Pipeline    can not   timeout within the specified interval duration and   can not   be cancelled as expected upon request   Pipeline Controller sets the  spec Status  and  spec StatusMessage  to signal  CustomRuns  about the  Cancellation   while  CustomRun  controller updates its  status conditions  as following once noticed the change on  spec Status       yaml status   conditions      type  Succeeded     status  False     reason  CustomRunCancelled          Specifying  Timeout   A custom task specification can be created with  Timeout  as follows      yaml apiVersion  tekton dev v1beta1 kind  CustomRun metadata    generateName  simpleexample spec    timeout  10s   set timeouts here    params        name  searching       value  the purpose of my existence   customRef      apiVersion  custom tekton dev v1alpha1     kind  Example     name  exampleName      Supporting timeouts is optional but recommended        Developer guide for custom controllers supporting  Timeout   1  Tekton controllers will never directly update the status of the  CustomRun       it is the responsibility of the custom task controller to support timeout     If timeout is not supported  it s the responsibility of the custom task    controller to reject  CustomRun s that specify a timeout value  2  When  CustomRun Spec Status  is updated to  RunCancelled   the custom task controller    MUST cancel the  CustomRun   Otherwise  pipeline level  Timeout  and     Cancellation  won t work for the Custom Task  3  A Custom Task controller can watch for this status update     i e   CustomRun Spec Status    RunCancelled   and or  CustomRun HasTimedOut       and take any corresponding actions  i e  a clean up e g   cancel a cloud build     stop the waiting timer  tear down the approval listener    4  Once resources or timers are cleaned up  while it is   REQUIRED   to set a     conditions  on the  CustomRun  s  status  of  Succeeded False  with an optional     Reason  of  CustomRunTimedOut   5   Timeout  is specified for each  retry attempt  instead of all  retries        Specifying  Retries   A custom task specification can be created with  Retries  as follows      yaml apiVersion  tekton dev v1beta1 kind  CustomRun metadata    generateName  simpleexample spec    retries  3   set retries   params        name  searching       value  the purpose of my existence   customRef      apiVersion  custom tekton dev v1alpha1     kind  Example     name  exampleName      Supporting retries is optional but recommended        Developer guide for custom controllers supporting  retries   1  Tekton controller only depends on  ConditionSucceeded  to determine the     termination status of a  CustomRun   therefore Custom task implementors    MUST NOT set  ConditionSucceeded  to  False  until all retries are exhausted  2  Those custom tasks who do not wish to support retry  can simply ignore it  3  It is recommended  that custom task should update the field  RetriesStatus     of a  CustomRun  on each retry performed by the custom task  4  Tekton controller does not validate that number of entries in  RetriesStatus     is same as specified value of retries count       Specifying  Parameters   If a custom task supports   parameters   tasks md parameters   you can use the  params  field in the  CustomRun  to specify their values      yaml spec    params        name  my param       value  chicken      If the custom task controller knows how to interpret the parameter value  it will do so  It might enforce that some parameter values must be specified  or reject unknown parameter values       Specifying workspaces  If the custom task supports it  you can provide   Workspaces   workspaces md  to share data with the custom task       yaml spec    workspaces        name  my workspace       emptyDir          Consult the documentation of the custom task that you are using to determine whether it supports workspaces and how to name them       Specifying a ServiceAccount  If the custom task supports it  you can execute the  CustomRun  with a specific set of credentials by specifying a  ServiceAccount  object name in the  serviceAccountName  field in your  CustomRun  definition  If you do not explicitly specify this  the  CustomRun  executes with the service account specified in the  configmap defaults   ConfigMap   If this default is not specified   CustomRuns  will execute with the   default  service account  https   kubernetes io docs tasks configure pod container configure service account  use the default service account to access the api server  set for the target   namespace   https   kubernetes io docs concepts overview working with objects namespaces        yaml spec    serviceAccountName  my account      Consult the documentation of the custom task that you are using to determine whether it supports a service account name      Monitoring execution status  As your  CustomRun  executes  its  status  field accumulates information on the execution of the  CustomRun   This information includes the current state of the  CustomRun   start and completion times  and any output  results  reported by the custom task controller       Status Reporting  When the  CustomRun Example   is validated and created  the Custom Task controller will be notified and is expected to begin doing some operation  When the operation begins  the controller   MUST   update the  CustomRun  s   status conditions  to report that it s ongoing      yaml status   conditions      type  Succeeded     status  Unknown      When the operation completes  if it was successful  the condition   MUST   report  status  True   and optionally a brief  reason  and human readable  message       yaml status   conditions      type  Succeeded     status  True     reason  ExampleComplete   optional     message  Yay  good times   optional      If the operation was  unsuccessful   the condition   MUST   report  status  False   and optionally a  reason  and human readable  message       yaml status   conditions      type  Succeeded     status  False     reason  ExampleFailed   optional     message  Oh no bad times   optional      If the  CustomRun  was  cancelled   the condition   MUST   report  status  False    reason  CustomRunCancelled   and optionally a human readable  message       yaml status   conditions      type  Succeeded     status  False     reason  CustomRunCancelled     message  Oh it s cancelled   optional      The following tables shows the overall status of a  CustomRun     status  Description                        unset  The custom task controller has not taken any action on the  CustomRun   Unknown The custom task controller has started execution and the  CustomRun  is ongoing  True The  CustomRun  completed successfully  False The  CustomRun  completed unsuccessfully  and all retries were exhausted   The  CustomRun  type s   status  will also allow controllers to report other fields  such as  startTime    completionTime    results   see below   and arbitrary context dependent fields the Custom Task author wants to report  A fully specified  CustomRun  status might look like       status   conditions      type  Succeeded     status  True     reason  ExampleComplete     message  Yay  good times   completionTime   2020 06 18T11 55 01Z    startTime   2020 06 18T11 55 01Z    results      name  first name     value  Bob     name  last name     value  Smith   arbitraryField  hello world   arbitraryStructuredField      listOfThings    a    b    c            Monitoring  Results   After the  CustomRun  completes  the custom task controller can report output values in the  results  field       results    name  my result   value  chicken         Code examples  To better understand  CustomRuns   study the following code examples      Example  CustomRun  with a referenced custom task   example customrun with a referenced custom task     Example  CustomRun  with an unnamed custom task   example customrun with an unnamed custom task     Example of specifying parameters   example of specifying parameters       Example  CustomRun  with a referenced custom task  In this example  a  CustomRun  named  my example run  invokes a custom task of the  v1alpha1  version of the  Example  kind in the  example dev  API group  with the name  my example task    In this case the custom task controller is expected to look up the  Example  resource named  my example task  and to use that configuration to configure the execution of the  CustomRun       yaml apiVersion  tekton dev v1beta1 kind  CustomRun metadata    name  my example run spec    customRef      apiVersion  example dev v1alpha1     kind  Example     name  my example task          Example  CustomRun  with an unnamed custom task  In this example  a  CustomRun  named  my example run  invokes a custom task of the  v1alpha1  version of the  Example  kind in the  example dev  API group  without a specified name   In this case the custom task controller is expected to provide some default behavior when the referenced task is unnamed      yaml apiVersion  tekton dev v1beta1 kind  CustomRun metadata    name  my example run spec    customRef      apiVersion  example dev v1alpha1     kind  Example          Example of specifying parameters  In this example  a  CustomRun  named  my example run  invokes a custom task  and specifies some parameter values to further configure the execution s behavior   In this case the custom task controller is expected to validate and interpret these parameter values and use them to configure the  CustomRun  s execution      yaml apiVersion  tekton dev v1alpha1 kind  CustomRun metadata    name  my example run spec    customRef      apiVersion  example dev v1alpha1     kind  Example     name  my example task   params        name  my first param       value  i m number one       name  my second param       value  close second


Answer:
<!--
---
linkTitle: "Windows"
weight: 306
---
-->

# Windows

- [Overview](#overview)
- [Scheduling Tasks on Windows Nodes](#scheduling-tasks-on-windows-nodes)
  - [Node Selectors](#node-selectors)
  - [Node Affinity](#node-affinity)

## Overview

If you need a Windows environment as part of a Tekton Task or Pipeline, you can include Windows container images in your Task steps. Because Windows containers can only run on a Windows host, you will need to have Windows nodes available in your Kubernetes cluster. You should read [Windows support in Kubernetes](https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/) to understand the functionality and limitations of Kubernetes on Windows.

Some important things to note about **Windows containers and Kubernetes**:

- Windows containers cannot run on a Linux host.
- Kubernetes does not support *Windows only* clusters. The Kubernetes control plane components can only run on Linux.
- Kubernetes currently only supports process isolated containers, which means a container's base image OS version **must** match that of the host OS. See [Windows container version compatibility](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility?tabs=windows-server-20H2%2Cwindows-10-20H2) for more information.
- A Kubernetes Pod cannot contain both Windows and Linux containers.

Some important things to note about **Windows support in Tekton**:

- A Task can only have Windows or Linux containers, but not both.
- A Pipeline can contain both Windows and Linux Tasks.
- In a mixed-OS cluster, TaskRuns and PipelineRuns will need to be scheduled to the correct node using one of the methods [described below](#scheduling-tasks-on-windows-nodes).
- Tekton's controller components can only run on Linux nodes.

## Scheduling Tasks on Windows Nodes

In order to ensure that Tasks are scheduled to a node with the correct host OS, you will need to update the TaskRun or PipelineRun spec with rules to define this behaviour. This can be done in a couple of different ways, but the simplest option is to specify a node selector.

### Node Selectors

Node selectors are the simplest way to schedule pods to a Windows or Linux node. By default, Kubernetes nodes include a label `kubernetes.io/os` to identify the host OS. The Kubelet populates this with `runtime.GOOS` as defined by Go. Use `spec.podTemplate.nodeSelector` (or `spec.taskRunSpecs[i].podTemplate.nodeSelector` in a PipelineRun) to schedule Tasks to a node with a specific label and value.

For example:

``` yaml
apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  name: windows-taskrun
spec:
  taskRef:
    name: windows-task
  podTemplate:
    nodeSelector:
      kubernetes.io/os: windows
---
apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  name: linux-taskrun
spec:
  taskRef:
    name: linux-task
  podTemplate:
    nodeSelector:
      kubernetes.io/os: linux
```

### Node Affinity

Node affinity can be used as an alternative method of defining the OS requirement of a Task. These rules can be set under `spec.podTemplate.affinity.nodeAffinity` in a TaskRun definition. The example below produces the same result as the previous example which used node selectors.

For example:

```yaml
apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  name: windows-taskrun
spec:
  taskRef:
    name: windows-task
  podTemplate:
    affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                - key: kubernetes.io/os
                  operator: In
                  values:
                  - windows
---
apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  name: linux-taskrun
spec:
  taskRef:
    name: linux-task
  podTemplate:
    affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                - key: kubernetes.io/os
                  operator: In
                  values:
                  - linux
```

linkTitle   Windows  weight  306            Windows     Overview   overview     Scheduling Tasks on Windows Nodes   scheduling tasks on windows nodes       Node Selectors   node selectors       Node Affinity   node affinity        Overview  If you need a Windows environment as part of a Tekton Task or Pipeline  you can include Windows container images in your Task steps  Because Windows containers can only run on a Windows host  you will need to have Windows nodes available in your Kubernetes cluster  You should read  Windows support in Kubernetes  https   kubernetes io docs setup production environment windows intro windows in kubernetes   to understand the functionality and limitations of Kubernetes on Windows   Some important things to note about   Windows containers and Kubernetes       Windows containers cannot run on a Linux host    Kubernetes does not support  Windows only  clusters  The Kubernetes control plane components can only run on Linux     Kubernetes currently only supports process isolated containers  which means a container s base image OS version   must   match that of the host OS  See  Windows container version compatibility  https   docs microsoft com en us virtualization windowscontainers deploy containers version compatibility tabs windows server 20H2 2Cwindows 10 20H2  for more information    A Kubernetes Pod cannot contain both Windows and Linux containers   Some important things to note about   Windows support in Tekton        A Task can only have Windows or Linux containers  but not both     A Pipeline can contain both Windows and Linux Tasks     In a mixed OS cluster  TaskRuns and PipelineRuns will need to be scheduled to the correct node using one of the methods  described below   scheduling tasks on windows nodes      Tekton s controller components can only run on Linux nodes      Scheduling Tasks on Windows Nodes  In order to ensure that Tasks are scheduled to a node with the correct host OS  you will need to update the TaskRun or PipelineRun spec with rules to define this behaviour  This can be done in a couple of different ways  but the simplest option is to specify a node selector        Node Selectors  Node selectors are the simplest way to schedule pods to a Windows or Linux node  By default  Kubernetes nodes include a label  kubernetes io os  to identify the host OS  The Kubelet populates this with  runtime GOOS  as defined by Go  Use  spec podTemplate nodeSelector   or  spec taskRunSpecs i  podTemplate nodeSelector  in a PipelineRun  to schedule Tasks to a node with a specific label and value   For example       yaml apiVersion  tekton dev v1 kind  TaskRun metadata    name  windows taskrun spec    taskRef      name  windows task   podTemplate      nodeSelector        kubernetes io os  windows     apiVersion  tekton dev v1 kind  TaskRun metadata    name  linux taskrun spec    taskRef      name  linux task   podTemplate      nodeSelector        kubernetes io os  linux          Node Affinity  Node affinity can be used as an alternative method of defining the OS requirement of a Task  These rules can be set under  spec podTemplate affinity nodeAffinity  in a TaskRun definition  The example below produces the same result as the previous example which used node selectors   For example      yaml apiVersion  tekton dev v1 kind  TaskRun metadata    name  windows taskrun spec    taskRef      name  windows task   podTemplate      affinity          nodeAffinity            requiredDuringSchedulingIgnoredDuringExecution              nodeSelectorTerms                  matchExpressions                    key  kubernetes io os                   operator  In                   values                      windows     apiVersion  tekton dev v1 kind  TaskRun metadata    name  linux taskrun spec    taskRef      name  linux task   podTemplate      affinity          nodeAffinity            requiredDuringSchedulingIgnoredDuringExecution              nodeSelectorTerms                  matchExpressions                    key  kubernetes io os                   operator  In                   values                      linux


Answer:
<!--
---
linkTitle: "Artifacts"
weight: 201
---
-->

# Artifacts

- [Overview](#overview)
- [Artifact Provenance Data](#artifact-provenance-data)
  - [Passing Artifacts between Steps](#passing-artifacts-between-steps)
  - [Passing Artifacts between Tasks](#passing-artifacts-between-tasks)

## Overview
> :seedling: **`Artifacts` is an [alpha](additional-configs.md#alpha-features) feature.**
> The `enable-artifacts` feature flag must be set to `"true"` to read or write artifacts in a step.

Artifacts provide a way to track the origin of data produced and consumed within your Tekton Tasks.

## Artifact Provenance Data
Artifacts fall into two categories:

 - Inputs: Artifacts downloaded and used by the Step/Task.
 - Outputs: Artifacts created and uploaded by the Step/Task.

Example Structure:
```json
{
  "inputs":[
    {
      "name": "<input-category-name>",
      "values": [
        {
          "uri": "pkg:github/package-url/purl-spec@244fd47e07d1004f0aed9c",
          "digest": { "sha256": "b35caccc..." }
        }
      ]
    }
  ],
  "outputs": [
    {
      "name": "<output-category-name>",
      "values": [
        {
          "uri": "pkg:oci/nginx:stable-alpine3.17-slim?repository_url=docker.io/library",
          "digest": {
            "sha256": "df85b9e3...",
            "sha1": "95588b8f..."
          }
        }
      ]
    }
  ]
}

```

The content is written by the `Step` to a file `$(step.artifacts.path)`:

```yaml
apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  generateName: step-artifacts-
spec:
  taskSpec:
    description: |
      A simple task that populates artifacts to TaskRun stepState
    steps:
      - name: artifacts-producer
        image: bash:latest
        script: |
          cat > $(step.artifacts.path) << EOF
          {
            "inputs":[
              {
                "name":"source",
                "values":[
                  {
                    "uri":"pkg:github/package-url/purl-spec@244fd47e07d1004f0aed9c",
                    "digest":{
                      "sha256":"b35cacccfdb1e24dc497d15d553891345fd155713ffe647c281c583269eaaae0"
                    }
                  }
                ]
              }
            ],
            "outputs":[
              {
                "name":"image",
                "values":[
                  {
                    "uri":"pkg:oci/nginx:stable-alpine3.17-slim?repository_url=docker.io/library",
                    "digest":{
                      "sha256":"df85b9e3983fe2ce20ef76ad675ecf435cc99fc9350adc54fa230bae8c32ce48",
                      "sha1":"95588b8f34c31eb7d62c92aaa4e6506639b06ef2"
                    }
                  }
                ]
              }
            ]
          }
          EOF
```

The content is written by the `Step` to a file `$(artifacts.path)`:

```yaml
apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  generateName: step-artifacts-
spec:
  taskSpec:
    description: |
      A simple task that populates artifacts to TaskRun stepState
    steps:
      - name: artifacts-producer
        image: bash:latest
        script: |
          cat > $(artifacts.path) << EOF
          {
            "inputs":[
              {
                "name":"source",
                "values":[
                  {
                    "uri":"pkg:github/package-url/purl-spec@244fd47e07d1004f0aed9c",
                    "digest":{
                      "sha256":"b35cacccfdb1e24dc497d15d553891345fd155713ffe647c281c583269eaaae0"
                    }
                  }
                ]
              }
            ],
            "outputs":[
              {
                "name":"image",
                "values":[
                  {
                    "uri":"pkg:oci/nginx:stable-alpine3.17-slim?repository_url=docker.io/library",
                    "digest":{
                      "sha256":"df85b9e3983fe2ce20ef76ad675ecf435cc99fc9350adc54fa230bae8c32ce48",
                      "sha1":"95588b8f34c31eb7d62c92aaa4e6506639b06ef2"
                    }
                  }
                ]
              }
            ]
          }
          EOF
```

It is recommended to use [purl format](https://github.com/package-url/purl-spec/blob/master/PURL-SPECIFICATION.rst) for artifacts uri as shown in the example.

### Output Artifacts in SLSA Provenance

Artifacts are classified as either:

- Build Outputs - packages, images, etc. that are being published by the build.
- Build Byproducts - logs, caches, etc. that are incidental artifacts that are produced by the build.

By default, Tekton Chains will consider all output artifacts as `byProducts` when generating in the [SLSA provenance](https://slsa.dev/spec/v1.0/provenance). In order to treat an artifact as a [subject](https://slsa.dev/spec/v1.0/provenance#schema) of the build, you must set a boolean field `"buildOutput": true` for the output artifact.

e.g.
```yaml
apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  generateName: step-artifacts-
spec:
  taskSpec:
    description: |
      A simple task that populates artifacts to TaskRun stepState
    steps:
      - name: artifacts-producer
        image: bash:latest
        script: |
          cat > $(artifacts.path) << EOF
          {
            "outputs":[
              {
                "name":"image",
                "buildOutput": true,
                "values":[
                  {
                    "uri":"pkg:oci/nginx:stable-alpine3.17-slim?repository_url=docker.io/library",
                    "digest":{
                      "sha256":"df85b9e3983fe2ce20ef76ad675ecf435cc99fc9350adc54fa230bae8c32ce48",
                      "sha1":"95588b8f34c31eb7d62c92aaa4e6506639b06ef2"
                    }
                  }
                ]
              }
            ]
          }
          EOF
```

This informs Tekton Chains your desire to handle the artifact.

> [!TIP]
> When authoring a `StepAction` or a `Task`, you can parametrize this field to allow users to indicate their desire depending on what they are uploading - this can be useful for actions that may produce either a build output or a byproduct depending on the context!

### Passing Artifacts between Steps
You can pass artifacts from one step to the next using:
- Specific Artifact: `$(steps.<step-name>.inputs.<artifact-category-name>)` or `$(steps.<step-name>.outputs.<artifact-category-name>)`

The example below shows how to access the previous' step artifacts from another step in the same task

```yaml
apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  generateName: step-artifacts-
spec:
  taskSpec:
    description: |
      A simple task that populates artifacts to TaskRun stepState
    steps:
      - name: artifacts-producer
        image: bash:latest
        script: |
          # the script is for creating the output artifacts
          cat > $(step.artifacts.path) << EOF
          {
            "inputs":[
              {
                "name":"source",
                "values":[
                  {
                    "uri":"pkg:github/package-url/purl-spec@244fd47e07d1004f0aed9c",
                    "digest":{
                      "sha256":"b35cacccfdb1e24dc497d15d553891345fd155713ffe647c281c583269eaaae0"
                    }
                  }
                ]
              }
            ],
            "outputs":[
              {
                "name":"image",
                "values":[
                  {
                    "uri":"pkg:oci/nginx:stable-alpine3.17-slim?repository_url=docker.io/library",
                    "digest":{
                      "sha256":"df85b9e3983fe2ce20ef76ad675ecf435cc99fc9350adc54fa230bae8c32ce48",
                      "sha1":"95588b8f34c31eb7d62c92aaa4e6506639b06ef2"
                    }
                  }
                ]
              }
            ]
          }
          EOF
      - name: artifacts-consumer
        image: bash:latest
        script: |
          echo $(steps.artifacts-producer.outputs.image)
```

The resolved value of `$(steps.<step-name>.outputs.<artifact-category-name>)` is the values of an artifact. For this example,
`$(steps.artifacts-producer.outputs.image)` is resolved to
```json
[
                  {
                    "uri":"pkg:oci/nginx:stable-alpine3.17-slim?repository_url=docker.io/library",
                    "digest":{
                      "sha256":"df85b9e3983fe2ce20ef76ad675ecf435cc99fc9350adc54fa230bae8c32ce48",
                      "sha1":"95588b8f34c31eb7d62c92aaa4e6506639b06ef2"
                    }
                  }
]
```

Upon resolution and execution of the `TaskRun`, the `Status` will look something like:

```json
{
  "artifacts": {
    "inputs": [
      {
        "name": "source",
        "values": [
          {
            "digest": {
              "sha256": "b35cacccfdb1e24dc497d15d553891345fd155713ffe647c281c583269eaaae0"
            },
            "uri": "pkg:github/package-url/purl-spec@244fd47e07d1004f0aed9c"
          }
        ]
      }
    ],
    "outputs": [
      {
        "name": "image",
        "values": [
          {
            "digest": {
              "sha1": "95588b8f34c31eb7d62c92aaa4e6506639b06ef2",
              "sha256": "df85b9e3983fe2ce20ef76ad675ecf435cc99fc9350adc54fa230bae8c32ce48"
            },
            "uri": "pkg:oci/nginx:stable-alpine3.17-slim?repository_url=docker.io/library"
          }
        ]
      }
    ]
  },
  "steps": [
    {
      "container": "step-artifacts-producer",
      "imageID": "docker.io/library/bash@sha256:5353512b79d2963e92a2b97d9cb52df72d32f94661aa825fcfa0aede73304743",
      "inputs": [
        {
          "name": "source",
          "values": [
            {
              "digest": {
                "sha256": "b35cacccfdb1e24dc497d15d553891345fd155713ffe647c281c583269eaaae0"
              },
              "uri": "pkg:github/package-url/purl-spec@244fd47e07d1004f0aed9c"
            }
          ]
        }
      ],
      "name": "artifacts-producer",
      "outputs": [
        {
          "name": "image",
          "values": [
            {
              "digest": {
                "sha1": "95588b8f34c31eb7d62c92aaa4e6506639b06ef2",
                "sha256": "df85b9e3983fe2ce20ef76ad675ecf435cc99fc9350adc54fa230bae8c32ce48"
              },
              "uri": "pkg:oci/nginx:stable-alpine3.17-slim?repository_url=docker.io/library"
            }
          ]
        }
      ],
      "terminated": {
        "containerID": "containerd://010f02d103d1db48531327a1fe09797c87c1d50b6a216892319b3af93e0f56e7",
        "exitCode": 0,
        "finishedAt": "2024-03-18T17:05:06Z",
        "message": "...",
        "reason": "Completed",
        "startedAt": "2024-03-18T17:05:06Z"
      },
      "terminationReason": "Completed"
    },
    {
      "container": "step-artifacts-consumer",
      "imageID": "docker.io/library/bash@sha256:5353512b79d2963e92a2b97d9cb52df72d32f94661aa825fcfa0aede73304743",
      "name": "artifacts-consumer",
      "terminated": {
        "containerID": "containerd://42428aa7e5a507eba924239f213d185dd4bc0882b6f217a79e6792f7fec3586e",
        "exitCode": 0,
        "finishedAt": "2024-03-18T17:05:06Z",
        "reason": "Completed",
        "startedAt": "2024-03-18T17:05:06Z"
      },
      "terminationReason": "Completed"
    }
  ]
}

```

### Passing Artifacts between Tasks
You can pass artifacts from one task to the another using:

- Specific Artifact: `$(tasks.<task-name>.inputs.<artifact-category-name>)` or `$(tasks.<task-name>.outputs.<artifact-category-name>)`

The example below shows how to access the previous' task artifacts from another task in a pipeline

```yaml
apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  generateName: pipelinerun-consume-tasks-artifacts
spec:
  pipelineSpec:
    tasks:
      - name: produce-artifacts-task
        taskSpec:
          description: |
            A simple task that produces artifacts
          steps:
            - name: produce-artifacts
              image: bash:latest
              script: |
                #!/usr/bin/env bash
                cat > $(artifacts.path) << EOF
                {
                  "inputs":[
                    {
                      "name":"input-artifacts",
                      "values":[
                        {
                          "uri":"pkg:example.github.com/inputs",
                          "digest":{
                            "sha256":"b35cacccfdb1e24dc497d15d553891345fd155713ffe647c281c583269eaaae0"
                          }
                        }
                      ]
                    }
                  ],
                  "outputs":[
                    {
                      "name":"image",
                      "values":[
                        {
                          "uri":"pkg:github/package-url/purl-spec@244fd47e07d1004f0aed9c",
                          "digest":{
                            "sha256":"df85b9e3983fe2ce20ef76ad675ecf435cc99fc9350adc54fa230bae8c32ce48",
                            "sha1":"95588b8f34c31eb7d62c92aaa4e6506639b06ef2"
                          }
                        }
                      ]
                    }
                  ]
                }
                EOF
      - name: consume-artifacts
        runAfter:
          - produce-artifacts-task
        taskSpec:
          steps:
            - name: artifacts-consumer-python
              image: python:latest
              script: |
                #!/usr/bin/env python3
                import json
                data = json.loads('$(tasks.produce-artifacts-task.outputs.image)')
                if data[0]['uri'] != "pkg:github/package-url/purl-spec@244fd47e07d1004f0aed9c":
                  exit(1)
```

Similar to Step Artifacts. The resolved value of `$(tasks.<task-name>.outputs.<artifact-category-name>)` is the values of an artifact. For this example,
`$(tasks.produce-artifacts-task.outputs.image)` is resolved to
```json
[
  {
    "uri":"pkg:example.github.com/inputs",
    "digest":{
      "sha256":"b35cacccfdb1e24dc497d15d553891345fd155713ffe647c281c583269eaaae0"
    }
 }
]
```
Upon resolution and execution of the `TaskRun`, the `Status` will look something like:
```json
{
 "artifacts": {
      "inputs": [
        {
          "name": "input-artifacts",
          "values": [
            {
              "digest": {
                "sha256": "b35cacccfdb1e24dc497d15d553891345fd155713ffe647c281c583269eaaae0"
              },
              "uri": "pkg:example.github.com/inputs"
            }
          ]
        }
      ],
      "outputs": [
        {
          "name": "image",
          "values": [
            {
              "digest": {
                "sha1": "95588b8f34c31eb7d62c92aaa4e6506639b06ef2",
                "sha256": "df85b9e3983fe2ce20ef76ad675ecf435cc99fc9350adc54fa230bae8c32ce48"
              },
              "uri": "pkg:github/package-url/purl-spec@244fd47e07d1004f0aed9c"
            }
          ]
        }
      ]
    },
    "completionTime": "2024-05-28T14:10:58Z",
    "conditions": [
      {
        "lastTransitionTime": "2024-05-28T14:10:58Z",
        "message": "All Steps have completed executing",
        "reason": "Succeeded",
        "status": "True",
        "type": "Succeeded"
      }
    ],
    "podName": "pipelinerun-consume-tasks-a41ee44e4f964e95adfd3aea417d52f90-pod",
    "provenance": {
      "featureFlags": {
        "AwaitSidecarReadiness": true,
        "Coschedule": "workspaces",
        "DisableAffinityAssistant": false,
        "DisableCredsInit": false,
        "DisableInlineSpec": "",
        "EnableAPIFields": "beta",
        "EnableArtifacts": true,
        "EnableCELInWhenExpression": false,
        "EnableConciseResolverSyntax": false,
        "EnableKeepPodOnCancel": false,
        "EnableParamEnum": false,
        "EnableProvenanceInStatus": true,
        "EnableStepActions": true,
        "EnableTektonOCIBundles": false,
        "EnforceNonfalsifiability": "none",
        "MaxResultSize": 4096,
        "RequireGitSSHSecretKnownHosts": false,
        "ResultExtractionMethod": "termination-message",
        "RunningInEnvWithInjectedSidecars": true,
        "ScopeWhenExpressionsToTask": false,
        "SendCloudEventsForRuns": false,
        "SetSecurityContext": false,
        "VerificationNoMatchPolicy": "ignore"
      }
    },
    "startTime": "2024-05-28T14:10:48Z",
    "steps": [
      {
        "container": "step-produce-artifacts",
        "imageID": "docker.io/library/bash@sha256:23f90212fd89e4c292d7b41386ef1a6ac2b8a02bbc6947680bfe184cbc1a2899",
        "name": "produce-artifacts",
        "terminated": {
          "containerID": "containerd://1291ce07b175a7897beee6ba62eaa1528427bacb1f76b31435eeba68828c445a",
          "exitCode": 0,
          "finishedAt": "2024-05-28T14:10:57Z",
          "message": "...",
          "reason": "Completed",
          "startedAt": "2024-05-28T14:10:57Z"
        },
        "terminationReason": "Completed"
      }
    ],
    "taskSpec": {
      "description": "A simple task that produces artifacts\n",
      "steps": [
        {
          "computeResources": {},
          "image": "bash:latest",
          "name": "produce-artifacts",
          "script": "#!/usr/bin/env bash\ncat > /tekton/artifacts/provenance.json << EOF\n{\n  \"inputs\":[\n    {\n      \"name\":\"input-artifacts\",\n      \"values\":[\n        {\n          \"uri\":\"pkg:example.github.com/inputs\",\n          \"digest\":{\n            \"sha256\":\"b35cacccfdb1e24dc497d15d553891345fd155713ffe647c281c583269eaaae0\"\n          }\n        }\n      ]\n    }\n  ],\n  \"outputs\":[\n    {\n      \"name\":\"image\",\n      \"values\":[\n        {\n          \"uri\":\"pkg:github/package-url/purl-spec@244fd47e07d1004f0aed9c\",\n          \"digest\":{\n            \"sha256\":\"df85b9e3983fe2ce20ef76ad675ecf435cc99fc9350adc54fa230bae8c32ce48\",\n            \"sha1\":\"95588b8f34c31eb7d62c92aaa4e6506639b06ef2\"\n          }\n        }\n      ]\n    }\n  ]\n}\nEOF\n"
        }
      ]
    }
}
```

linkTitle   Artifacts  weight  201            Artifacts     Overview   overview     Artifact Provenance Data   artifact provenance data       Passing Artifacts between Steps   passing artifacts between steps       Passing Artifacts between Tasks   passing artifacts between tasks        Overview    seedling     Artifacts  is an  alpha  additional configs md alpha features  feature      The  enable artifacts  feature flag must be set to   true   to read or write artifacts in a step   Artifacts provide a way to track the origin of data produced and consumed within your Tekton Tasks      Artifact Provenance Data Artifacts fall into two categories      Inputs  Artifacts downloaded and used by the Step Task     Outputs  Artifacts created and uploaded by the Step Task   Example Structure     json      inputs                 name     input category name            values                          uri    pkg github package url purl spec 244fd47e07d1004f0aed9c               digest      sha256    b35caccc                                       outputs                  name     output category name           values                          uri    pkg oci nginx stable alpine3 17 slim repository url docker io library              digest                  sha256    df85b9e3                   sha1    95588b8f                                                     The content is written by the  Step  to a file    step artifacts path        yaml apiVersion  tekton dev v1 kind  TaskRun metadata    generateName  step artifacts  spec    taskSpec      description          A simple task that populates artifacts to TaskRun stepState     steps          name  artifacts producer         image  bash latest         script              cat     step artifacts path     EOF                          inputs                                     name   source                    values                                             uri   pkg github package url purl spec 244fd47e07d1004f0aed9c                        digest                           sha256   b35cacccfdb1e24dc497d15d553891345fd155713ffe647c281c583269eaaae0                                                                                outputs                                     name   image                    values                                             uri   pkg oci nginx stable alpine3 17 slim repository url docker io library                        digest                           sha256   df85b9e3983fe2ce20ef76ad675ecf435cc99fc9350adc54fa230bae8c32ce48                          sha1   95588b8f34c31eb7d62c92aaa4e6506639b06ef2                                                                                EOF      The content is written by the  Step  to a file    artifacts path        yaml apiVersion  tekton dev v1 kind  TaskRun metadata    generateName  step artifacts  spec    taskSpec      description          A simple task that populates artifacts to TaskRun stepState     steps          name  artifacts producer         image  bash latest         script              cat     artifacts path     EOF                          inputs                                     name   source                    values                                             uri   pkg github package url purl spec 244fd47e07d1004f0aed9c                        digest                           sha256   b35cacccfdb1e24dc497d15d553891345fd155713ffe647c281c583269eaaae0                                                                                outputs                                     name   image                    values                                             uri   pkg oci nginx stable alpine3 17 slim repository url docker io library                        digest                           sha256   df85b9e3983fe2ce20ef76ad675ecf435cc99fc9350adc54fa230bae8c32ce48                          sha1   95588b8f34c31eb7d62c92aaa4e6506639b06ef2                                                                                EOF      It is recommended to use  purl format  https   github com package url purl spec blob master PURL SPECIFICATION rst  for artifacts uri as shown in the example        Output Artifacts in SLSA Provenance  Artifacts are classified as either     Build Outputs   packages  images  etc  that are being published by the build    Build Byproducts   logs  caches  etc  that are incidental artifacts that are produced by the build   By default  Tekton Chains will consider all output artifacts as  byProducts  when generating in the  SLSA provenance  https   slsa dev spec v1 0 provenance   In order to treat an artifact as a  subject  https   slsa dev spec v1 0 provenance schema  of the build  you must set a boolean field   buildOutput   true  for the output artifact   e g       yaml apiVersion  tekton dev v1 kind  TaskRun metadata    generateName  step artifacts  spec    taskSpec      description          A simple task that populates artifacts to TaskRun stepState     steps          name  artifacts producer         image  bash latest         script              cat     artifacts path     EOF                          outputs                                     name   image                    buildOutput   true                   values                                             uri   pkg oci nginx stable alpine3 17 slim repository url docker io library                        digest                           sha256   df85b9e3983fe2ce20ef76ad675ecf435cc99fc9350adc54fa230bae8c32ce48                          sha1   95588b8f34c31eb7d62c92aaa4e6506639b06ef2                                                                                EOF      This informs Tekton Chains your desire to handle the artifact       TIP     When authoring a  StepAction  or a  Task   you can parametrize this field to allow users to indicate their desire depending on what they are uploading   this can be useful for actions that may produce either a build output or a byproduct depending on the context       Passing Artifacts between Steps You can pass artifacts from one step to the next using    Specific Artifact     steps  step name  inputs  artifact category name    or    steps  step name  outputs  artifact category name     The example below shows how to access the previous  step artifacts from another step in the same task     yaml apiVersion  tekton dev v1 kind  TaskRun metadata    generateName  step artifacts  spec    taskSpec      description          A simple task that populates artifacts to TaskRun stepState     steps          name  artifacts producer         image  bash latest         script                the script is for creating the output artifacts           cat     step artifacts path     EOF                          inputs                                     name   source                    values                                             uri   pkg github package url purl spec 244fd47e07d1004f0aed9c                        digest                           sha256   b35cacccfdb1e24dc497d15d553891345fd155713ffe647c281c583269eaaae0                                                                                outputs                                     name   image                    values                                             uri   pkg oci nginx stable alpine3 17 slim repository url docker io library                        digest                           sha256   df85b9e3983fe2ce20ef76ad675ecf435cc99fc9350adc54fa230bae8c32ce48                          sha1   95588b8f34c31eb7d62c92aaa4e6506639b06ef2                                                                                EOF         name  artifacts consumer         image  bash latest         script              echo   steps artifacts producer outputs image        The resolved value of    steps  step name  outputs  artifact category name    is the values of an artifact  For this example      steps artifacts producer outputs image   is resolved to     json                                            uri   pkg oci nginx stable alpine3 17 slim repository url docker io library                        digest                           sha256   df85b9e3983fe2ce20ef76ad675ecf435cc99fc9350adc54fa230bae8c32ce48                          sha1   95588b8f34c31eb7d62c92aaa4e6506639b06ef2                                                    Upon resolution and execution of the  TaskRun   the  Status  will look something like      json      artifacts          inputs                      name    source            values                              digest                    sha256    b35cacccfdb1e24dc497d15d553891345fd155713ffe647c281c583269eaaae0                              uri    pkg github package url purl spec 244fd47e07d1004f0aed9c                                            outputs                      name    image            values                              digest                    sha1    95588b8f34c31eb7d62c92aaa4e6506639b06ef2                  sha256    df85b9e3983fe2ce20ef76ad675ecf435cc99fc9350adc54fa230bae8c32ce48                              uri    pkg oci nginx stable alpine3 17 slim repository url docker io library                                              steps                  container    step artifacts producer          imageID    docker io library bash sha256 5353512b79d2963e92a2b97d9cb52df72d32f94661aa825fcfa0aede73304743          inputs                          name    source              values                                  digest                      sha256    b35cacccfdb1e24dc497d15d553891345fd155713ffe647c281c583269eaaae0                                  uri    pkg github package url purl spec 244fd47e07d1004f0aed9c                                                      name    artifacts producer          outputs                          name    image              values                                  digest                      sha1    95588b8f34c31eb7d62c92aaa4e6506639b06ef2                    sha256    df85b9e3983fe2ce20ef76ad675ecf435cc99fc9350adc54fa230bae8c32ce48                                  uri    pkg oci nginx stable alpine3 17 slim repository url docker io library                                                      terminated              containerID    containerd   010f02d103d1db48531327a1fe09797c87c1d50b6a216892319b3af93e0f56e7            exitCode   0           finishedAt    2024 03 18T17 05 06Z            message                   reason    Completed            startedAt    2024 03 18T17 05 06Z                  terminationReason    Completed                      container    step artifacts consumer          imageID    docker io library bash sha256 5353512b79d2963e92a2b97d9cb52df72d32f94661aa825fcfa0aede73304743          name    artifacts consumer          terminated              containerID    containerd   42428aa7e5a507eba924239f213d185dd4bc0882b6f217a79e6792f7fec3586e            exitCode   0           finishedAt    2024 03 18T17 05 06Z            reason    Completed            startedAt    2024 03 18T17 05 06Z                  terminationReason    Completed                        Passing Artifacts between Tasks You can pass artifacts from one task to the another using     Specific Artifact     tasks  task name  inputs  artifact category name    or    tasks  task name  outputs  artifact category name     The example below shows how to access the previous  task artifacts from another task in a pipeline     yaml apiVersion  tekton dev v1 kind  PipelineRun metadata    generateName  pipelinerun consume tasks artifacts spec    pipelineSpec      tasks          name  produce artifacts task         taskSpec            description                A simple task that produces artifacts           steps                name  produce artifacts               image  bash latest               script                       usr bin env bash                 cat     artifacts path     EOF                                      inputs                                                 name   input artifacts                          values                                                         uri   pkg example github com inputs                              digest                                 sha256   b35cacccfdb1e24dc497d15d553891345fd155713ffe647c281c583269eaaae0                                                                                outputs                                                 name   image                          values                                                         uri   pkg github package url purl spec 244fd47e07d1004f0aed9c                              digest                                 sha256   df85b9e3983fe2ce20ef76ad675ecf435cc99fc9350adc54fa230bae8c32ce48                                sha1   95588b8f34c31eb7d62c92aaa4e6506639b06ef2                                                                                EOF         name  consume artifacts         runAfter              produce artifacts task         taskSpec            steps                name  artifacts consumer python               image  python latest               script                       usr bin env python3                 import json                 data   json loads    tasks produce artifacts task outputs image                    if data 0   uri       pkg github package url purl spec 244fd47e07d1004f0aed9c                     exit 1        Similar to Step Artifacts  The resolved value of    tasks  task name  outputs  artifact category name    is the values of an artifact  For this example     tasks produce artifacts task outputs image   is resolved to    json            uri   pkg example github com inputs        digest           sha256   b35cacccfdb1e24dc497d15d553891345fd155713ffe647c281c583269eaaae0                 Upon resolution and execution of the  TaskRun   the  Status  will look something like     json     artifacts            inputs                          name    input artifacts              values                                  digest                      sha256    b35cacccfdb1e24dc497d15d553891345fd155713ffe647c281c583269eaaae0                                  uri    pkg example github com inputs                                                      outputs                          name    image              values                                  digest                      sha1    95588b8f34c31eb7d62c92aaa4e6506639b06ef2                    sha256    df85b9e3983fe2ce20ef76ad675ecf435cc99fc9350adc54fa230bae8c32ce48                                  uri    pkg github package url purl spec 244fd47e07d1004f0aed9c                                                          completionTime    2024 05 28T14 10 58Z        conditions                      lastTransitionTime    2024 05 28T14 10 58Z            message    All Steps have completed executing            reason    Succeeded            status    True            type    Succeeded                      podName    pipelinerun consume tasks a41ee44e4f964e95adfd3aea417d52f90 pod        provenance            featureFlags              AwaitSidecarReadiness   true           Coschedule    workspaces            DisableAffinityAssistant   false           DisableCredsInit   false           DisableInlineSpec                EnableAPIFields    beta            EnableArtifacts   true           EnableCELInWhenExpression   false           EnableConciseResolverSyntax   false           EnableKeepPodOnCancel   false           EnableParamEnum   false           EnableProvenanceInStatus   true           EnableStepActions   true           EnableTektonOCIBundles   false           EnforceNonfalsifiability    none            MaxResultSize   4096           RequireGitSSHSecretKnownHosts   false           ResultExtractionMethod    termination message            RunningInEnvWithInjectedSidecars   true           ScopeWhenExpressionsToTask   false           SendCloudEventsForRuns   false           SetSecurityContext   false           VerificationNoMatchPolicy    ignore                      startTime    2024 05 28T14 10 48Z        steps                      container    step produce artifacts            imageID    docker io library bash sha256 23f90212fd89e4c292d7b41386ef1a6ac2b8a02bbc6947680bfe184cbc1a2899            name    produce artifacts            terminated                containerID    containerd   1291ce07b175a7897beee6ba62eaa1528427bacb1f76b31435eeba68828c445a              exitCode   0             finishedAt    2024 05 28T14 10 57Z              message                     reason    Completed              startedAt    2024 05 28T14 10 57Z                      terminationReason    Completed                      taskSpec            description    A simple task that produces artifacts n          steps                          computeResources                  image    bash latest              name    produce artifacts              script       usr bin env bash ncat    tekton artifacts provenance json    EOF n  n    inputs     n      n        name     input artifacts    n        values     n          n            uri     pkg example github com inputs    n            digest     n              sha256     b35cacccfdb1e24dc497d15d553891345fd155713ffe647c281c583269eaaae0   n            n          n        n      n     n    outputs     n      n        name     image    n        values     n          n            uri     pkg github package url purl spec 244fd47e07d1004f0aed9c    n            digest     n              sha256     df85b9e3983fe2ce20ef76ad675ecf435cc99fc9350adc54fa230bae8c32ce48    n              sha1     95588b8f34c31eb7d62c92aaa4e6506639b06ef2   n            n          n        n      n    n  nEOF n


tekton Install Tekton Pipelines weight 101 Install Tekton Pipelines on your cluster title Install Tekton Pipelines

Answer:
To view the full contents of this page, go to the
Tekton website.

This guide explains how to install Tekton Pipelines.

## Prerequisites

-   A [Kubernetes cluster][k8s] running version 1.28 or later.
-   [Kubectl][].
-   Grant `cluster-admin` privileges to the current user. See the [Kubernetes
    role-based access control (RBAC) docs][rbac] for more information.
-   (Optional) Install a [Metrics Server][metrics] if you need support for high
    availability use cases.

See the [local installation guide][local-install] if you want to test Tekton on
your computer.

## Installation

To install Tekton Pipelines on a Kubernetes cluster:

1. Run one of the following commands depending on which version of Tekton
   Pipelines you want to install:

   - **Latest official release:**

     ```bash
     kubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml
     ```

      Note: These instructions are ideal as a quick start installation guide with Tekton Pipelines and not meant for the production use. Please refer to the [operator](https://github.com/tektoncd/operator) to install, upgrade and manage Tekton projects.

   - **Nightly release:**

     ```bash
     kubectl apply --filename https://storage.googleapis.com/tekton-releases-nightly/pipeline/latest/release.yaml
     ```

   - **Specific release:**

     ```bash
      kubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/previous/<version_number>/release.yaml
     ```

     Replace `<version_number>` with the numbered version you want to install.
     For example, `v0.26.0`.

   - **Untagged release:**

     If your container runtime does not support `image-reference:tag@digest`:

     ```bash
     kubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/latest/release.notags.yaml
     ```

Multi-tenant installation is only partially supported today, read the [guide](./developers/multi-tenant-support.md)
for reference.

1. Monitor the installation:

   ```bash
   kubectl get pods --namespace tekton-pipelines --watch
   ```

   When all components show `1/1` under the `READY` column, the installation is
   complete. Hit *Ctrl + C* to stop monitoring.

Congratulations! You have successfully installed Tekton Pipelines on your
Kubernetes cluster.

## Additional configuration options

You can enable additional alpha and beta features, customize execution
parameters, configure availability, and many more options. See the
[addition configurations options](./additional-configs.md) for more information.

## Next steps

To get started with Tekton check the [Introductory tutorials][quickstarts],
the [how-to guides][howtos], and the [examples folder][examples].

---

Except as otherwise noted, the content of this page is licensed under the
[Creative Commons Attribution 4.0 License][cca4], and code samples are licensed
under the [Apache 2.0 License][apache2l].

[quickstarts]: https://tekton.dev/docs/getting-started/
[howtos]: https://tekton.dev/docs/how-to-guides/
[examples]: https://github.com/tektoncd/pipeline/tree/main/examples/
[cca4]: https://creativecommons.org/licenses/by/4.0/
[apache2l]: https://www.apache.org/licenses/LICENSE-2.0
[k8s]: https://www.downloadkubernetes.com/
[kubectl]: https://www.downloadkubernetes.com/
[rbac]: https://kubernetes.io/docs/reference/access-authn-authz/rbac/
[metrics]: https://github.com/kubernetes-sigs/metrics-server
[local-install]: https://tekton.dev/docs/installation/local-installation/

title   Install Tekton Pipelines  linkTitle   Install Tekton Pipelines  weight  101 description      Install Tekton Pipelines on your cluster           To view the full contents of this page  go to the   a href  http   tekton dev docs installation pipelines   Tekton website  a         This guide explains how to install Tekton Pipelines      Prerequisites      A  Kubernetes cluster  k8s  running version 1 28 or later       Kubectl         Grant  cluster admin  privileges to the current user  See the  Kubernetes     role based access control  RBAC  docs  rbac  for more information       Optional  Install a  Metrics Server  metrics  if you need support for high     availability use cases   See the  local installation guide  local install  if you want to test Tekton on your computer      Installation     To install Tekton Pipelines on a Kubernetes cluster   1  Run one of the following commands depending on which version of Tekton    Pipelines you want to install          Latest official release             bash      kubectl apply   filename https   storage googleapis com tekton releases pipeline latest release yaml                      Note  These instructions are ideal as a quick start installation guide with Tekton Pipelines and not meant for the production use  Please refer to the  operator  https   github com tektoncd operator  to install  upgrade and manage Tekton projects           Nightly release             bash      kubectl apply   filename https   storage googleapis com tekton releases nightly pipeline latest release yaml                  Specific release             bash       kubectl apply   filename https   storage googleapis com tekton releases pipeline previous  version number  release yaml                Replace   version number   with the numbered version you want to install       For example   v0 26 0           Untagged release          If your container runtime does not support  image reference tag digest            bash      kubectl apply   filename https   storage googleapis com tekton releases pipeline latest release notags yaml           Multi tenant installation is only partially supported today  read the  guide    developers multi tenant support md  for reference   1  Monitor the installation         bash    kubectl get pods   namespace tekton pipelines   watch            When all components show  1 1  under the  READY  column  the installation is    complete  Hit  Ctrl   C  to stop monitoring   Congratulations  You have successfully installed Tekton Pipelines on your Kubernetes cluster                      Additional configuration options  You can enable additional alpha and beta features  customize execution parameters  configure availability  and many more options  See the  addition configurations options    additional configs md  for more information      Next steps  To get started with Tekton check the  Introductory tutorials  quickstarts   the  how to guides  howtos   and the  examples folder  examples          Except as otherwise noted  the content of this page is licensed under the  Creative Commons Attribution 4 0 License  cca4   and code samples are licensed under the  Apache 2 0 License  apache2l      quickstarts   https   tekton dev docs getting started   howtos   https   tekton dev docs how to guides   examples   https   github com tektoncd pipeline tree main examples   cca4   https   creativecommons org licenses by 4 0   apache2l   https   www apache org licenses LICENSE 2 0  k8s   https   www downloadkubernetes com   kubectl   https   www downloadkubernetes com   rbac   https   kubernetes io docs reference access authn authz rbac   metrics   https   github com kubernetes sigs metrics server  local install   https   tekton dev docs installation local installation