tekton remained in alpha while the other resource kinds were promoted to beta Replacing PipelineResources with Tasks Replacing PipelineResources with Tasks weight 207

Answer:
<!--
---
linkTitle: "Replacing PipelineResources with Tasks"
weight: 207
---
-->

## Replacing PipelineResources with Tasks

`PipelineResources` remained in alpha while the other resource kinds were promoted to beta.
Since then, **`PipelineResources` have been removed**.
Read more about the deprecation in [TEP-0074](https://github.com/tektoncd/community/blob/main/teps/0074-deprecate-pipelineresources.md).

_More on the reasoning and what's left to do in
[Why aren't PipelineResources in Beta?](resources.md#why-aren-t-pipelineresources-in-beta)._

To ease migration away from `PipelineResources`
[some types have an equivalent `Task` in the Catalog](#replacing-pipelineresources-with-tasks).
To use these replacement `Tasks` you will need to combine them with your existing `Tasks` via a `Pipeline`.

For example, if you were using this `Task` which was fetching from `git` and building with
`Kaniko`:

```yaml
apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
  name: build-push-kaniko
spec:
  inputs:
    resources:
      - name: workspace
        type: git
    params:
      - name: pathToDockerFile
        description: The path to the dockerfile to build
        default: /workspace/workspace/Dockerfile
      - name: pathToContext
        description: The build context used by Kaniko
        default: /workspace/workspace
  outputs:
    resources:
      - name: builtImage
        type: image
  steps:
    - name: build-and-push
      image: gcr.io/kaniko-project/executor:v0.17.1
      env:
        - name: "DOCKER_CONFIG"
          value: "/tekton/home/.docker/"
      args:
        - --dockerfile=$(inputs.params.pathToDockerFile)
        - --destination=$(outputs.resources.builtImage.url)
        - --context=$(inputs.params.pathToContext)
        - --oci-layout-path=$(inputs.resources.builtImage.path)
      securityContext:
        runAsUser: 0
```

To do the same thing with the `git` catalog `Task` and the kaniko `Task` you will need to combine them in a
`Pipeline`.

For example this Pipeline uses the Kaniko and `git` catalog Tasks:

```yaml
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: kaniko-pipeline
spec:
  params:
    - name: git-url
    - name: git-revision
    - name: image-name
    - name: path-to-image-context
    - name: path-to-dockerfile
  workspaces:
    - name: git-source
  tasks:
    - name: fetch-from-git
      taskRef:
        name: git-clone
      params:
        - name: url
          value: $(params.git-url)
        - name: revision
          value: $(params.git-revision)
      workspaces:
        - name: output
          workspace: git-source
    - name: build-image
      taskRef:
        name: kaniko
      params:
        - name: IMAGE
          value: $(params.image-name)
        - name: CONTEXT
          value: $(params.path-to-image-context)
        - name: DOCKERFILE
          value: $(params.path-to-dockerfile)
      workspaces:
        - name: source
          workspace: git-source
  # If you want you can add a Task that uses the IMAGE_DIGEST from the kaniko task
  # via $(tasks.build-image.results.IMAGE_DIGEST) - this was a feature we hadn't been
  # able to fully deliver with the Image PipelineResource!
```

_Note that [the `image` `PipelineResource` is gone in this example](#replacing-an-image-resource) (replaced with
a [`result`](tasks.md#emitting-results)), and also that now the `Task` doesn't need to know anything
about where the files come from that it builds from._

### Replacing a `git` resource

You can replace a `git` resource with the [`git-clone` Catalog `Task`](https://github.com/tektoncd/catalog/tree/main/task/git-clone).

### Replacing a `pullrequest` resource

You can replace a `pullrequest` resource with the [`pullrequest` Catalog `Task`](https://github.com/tektoncd/catalog/tree/main/task/pull-request).

### Replacing a `gcs` resource

You can replace a `gcs` resource with the [`gcs` Catalog `Task`](https://github.com/tektoncd/catalog/tree/main/task/gcs-generic).

### Replacing an `image` resource

Since the `image` resource is simply a way to share the digest of a built image with subsequent
`Tasks` in your `Pipeline`, you can use [`Task` results](tasks.md#emitting-results) to
achieve equivalent functionality.

For examples of replacing an `image` resource, see the following Catalog `Tasks`:

- The [Kaniko Catalog `Task`](https://github.com/tektoncd/catalog/blob/v1beta1/kaniko/)
  illustrates how to write the digest of an image to a result.
- The [Buildah Catalog `Task`](https://github.com/tektoncd/catalog/blob/v1beta1/buildah/)
  illustrates how to accept an image digest as a parameter.

### Replacing a `cluster` resource

You can replace a `cluster` resource with the [`kubeconfig-creator` Catalog `Task`](https://github.com/tektoncd/catalog/tree/main/task/kubeconfig-creator).

### Replacing a `cloudEvent` resource

You can replace a `cloudEvent` resource with the [`CloudEvent` Catalog `Task`](https://github.com/tektoncd/catalog/tree/main/task/cloudevent).

linkTitle   Replacing PipelineResources with Tasks  weight  207             Replacing PipelineResources with Tasks   PipelineResources  remained in alpha while the other resource kinds were promoted to beta  Since then     PipelineResources  have been removed    Read more about the deprecation in  TEP 0074  https   github com tektoncd community blob main teps 0074 deprecate pipelineresources md     More on the reasoning and what s left to do in  Why aren t PipelineResources in Beta   resources md why aren t pipelineresources in beta     To ease migration away from  PipelineResources   some types have an equivalent  Task  in the Catalog   replacing pipelineresources with tasks   To use these replacement  Tasks  you will need to combine them with your existing  Tasks  via a  Pipeline    For example  if you were using this  Task  which was fetching from  git  and building with  Kaniko       yaml apiVersion  tekton dev v1alpha1 kind  Task metadata    name  build push kaniko spec    inputs      resources          name  workspace         type  git     params          name  pathToDockerFile         description  The path to the dockerfile to build         default   workspace workspace Dockerfile         name  pathToContext         description  The build context used by Kaniko         default   workspace workspace   outputs      resources          name  builtImage         type  image   steps        name  build and push       image  gcr io kaniko project executor v0 17 1       env            name   DOCKER CONFIG            value    tekton home  docker         args              dockerfile   inputs params pathToDockerFile              destination   outputs resources builtImage url              context   inputs params pathToContext              oci layout path   inputs resources builtImage path        securityContext          runAsUser  0      To do the same thing with the  git  catalog  Task  and the kaniko  Task  you will need to combine them in a  Pipeline    For example this Pipeline uses the Kaniko and  git  catalog Tasks      yaml apiVersion  tekton dev v1beta1 kind  Pipeline metadata    name  kaniko pipeline spec    params        name  git url       name  git revision       name  image name       name  path to image context       name  path to dockerfile   workspaces        name  git source   tasks        name  fetch from git       taskRef          name  git clone       params            name  url           value    params git url            name  revision           value    params git revision        workspaces            name  output           workspace  git source       name  build image       taskRef          name  kaniko       params            name  IMAGE           value    params image name            name  CONTEXT           value    params path to image context            name  DOCKERFILE           value    params path to dockerfile        workspaces            name  source           workspace  git source     If you want you can add a Task that uses the IMAGE DIGEST from the kaniko task     via   tasks build image results IMAGE DIGEST    this was a feature we hadn t been     able to fully deliver with the Image PipelineResource        Note that  the  image   PipelineResource  is gone in this example   replacing an image resource   replaced with a   result   tasks md emitting results    and also that now the  Task  doesn t need to know anything about where the files come from that it builds from        Replacing a  git  resource  You can replace a  git  resource with the   git clone  Catalog  Task   https   github com tektoncd catalog tree main task git clone        Replacing a  pullrequest  resource  You can replace a  pullrequest  resource with the   pullrequest  Catalog  Task   https   github com tektoncd catalog tree main task pull request        Replacing a  gcs  resource  You can replace a  gcs  resource with the   gcs  Catalog  Task   https   github com tektoncd catalog tree main task gcs generic        Replacing an  image  resource  Since the  image  resource is simply a way to share the digest of a built image with subsequent  Tasks  in your  Pipeline   you can use   Task  results  tasks md emitting results  to achieve equivalent functionality   For examples of replacing an  image  resource  see the following Catalog  Tasks      The  Kaniko Catalog  Task   https   github com tektoncd catalog blob v1beta1 kaniko     illustrates how to write the digest of an image to a result    The  Buildah Catalog  Task   https   github com tektoncd catalog blob v1beta1 buildah     illustrates how to accept an image digest as a parameter       Replacing a  cluster  resource  You can replace a  cluster  resource with the   kubeconfig creator  Catalog  Task   https   github com tektoncd catalog tree main task kubeconfig creator        Replacing a  cloudEvent  resource  You can replace a  cloudEvent  resource with the   CloudEvent  Catalog  Task   https   github com tektoncd catalog tree main task cloudevent


tekton Get started with Resolvers weight 103 Getting Started with Resolvers

Answer:
<!--
---
linkTitle: "Get started with Resolvers"
weight: 103
---
-->

# Getting Started with Resolvers

## Introduction

This guide will take you from an empty Kubernetes cluster to a
functioning Tekton Pipelines installation and a PipelineRun executing
with a Pipeline stored in a git repo.

## Prerequisites

- A computer with
  [`kubectl`](https://kubernetes.io/docs/tasks/tools/#kubectl).
- A Kubernetes cluster running at least Kubernetes 1.28. A [`kind`
  cluster](https://kind.sigs.k8s.io/docs/user/quick-start/#installation)
  should work fine for following the guide on your local machine.
- An image registry that you can push images to. If you're using `kind`
  make sure your `KO_DOCKER_REPO` environment variable is set to
  `kind.local`.
- A publicly available git repository where you can put a pipeline yaml
  file.

## Step 1: Install Tekton Pipelines and the Resolvers

See [the installation instructions for Tekton Pipeline](./install.md#installing-tekton-pipelines-on-kubernetes), and
[the installation instructions for the built-in resolvers](./install.md#installing-and-configuring-remote-task-and-pipeline-resolution).

## Step 2: Ensure Pipelines is configured to enable resolvers

Starting with v0.41.0, remote resolvers for Tekton Pipelines are enabled by default,
but can be disabled via feature flags in the `resolvers-feature-flags` configmap in
the `tekton-pipelines-resolvers` namespace. Check that configmap to verify that the
resolvers you wish to have enabled are set to `"true"`.

The feature flags for the built-in resolvers are:

* The `bundles` resolver: `enable-bundles-resolver`
* The `git` resolver: `enable-git-resolver`
* The `hub` resolver: `enable-hub-resolver`
* The `cluster` resolver: `enable-cluster-resolver`

## Step 3: Try it out!

In order to test out your install you'll need a Pipeline stored in a
public git repository. First cd into a clone of your repo and then
create a new branch:

```sh
# checkout a new branch in the public repo you're using
git checkout -b add-a-simple-pipeline
```

Then create a basic pipeline:

```sh
cat <<"EOF" > pipeline.yaml
kind: Pipeline
apiVersion: tekton.dev/v1beta1
metadata:
  name: a-simple-pipeline
spec:
  params:
  - name: username
  tasks:
  - name: task-1
    params:
    - name: username
      value: $(params.username)
    taskSpec:
      params:
      - name: username
      steps:
      - image: alpine:3.15
        script: |
          echo "hello $(params.username)"
EOF
```

Commit the pipeline and push it to your git repo:

```sh
git add ./pipeline.yaml
git commit -m "Add a basic pipeline to test Tekton Pipeline remote resolution"

# push to your publicly accessible repository, replacing origin with
# your git remote's name
git push origin add-a-simple-pipeline
```

And finally create a `PipelineRun` that uses your pipeline:

```sh
# first assign your public repo's url to an environment variable
REPO_URL=# insert your repo's url here

# create a pipelinerun yaml file
cat <<EOF > pipelinerun.yaml
kind: PipelineRun
apiVersion: tekton.dev/v1beta1
metadata:
  name: run-basic-pipeline-from-git
spec:
  pipelineRef:
    resolver: git
    params:
    - name: url
      value: ${REPO_URL}
    - name: revision
      value: add-a-simple-pipeline
    - name: pathInRepo
      value: pipeline.yaml
  params:
  - name: username
    value: liza
EOF

# execute the pipelinerun
kubectl apply -f ./pipelinerun.yaml
```

## Step 4: Monitor the PipelineRun

First let's watch the PipelineRun to see if it succeeds:

```sh
kubectl get pipelineruns -w
```

Shortly the PipelineRun should move into a Succeeded state.

Now we can check the logs of the PipelineRun's only task:

```sh
kubectl logs run-basic-pipeline-from-git-task-1-pod
# This should print "hello liza"
```

---

Except as otherwise noted, the content of this page is licensed under the
[Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
and code samples are licensed under the
[Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).

linkTitle   Get started with Resolvers  weight  103             Getting Started with Resolvers     Introduction  This guide will take you from an empty Kubernetes cluster to a functioning Tekton Pipelines installation and a PipelineRun executing with a Pipeline stored in a git repo      Prerequisites    A computer with     kubectl   https   kubernetes io docs tasks tools  kubectl     A Kubernetes cluster running at least Kubernetes 1 28  A   kind    cluster  https   kind sigs k8s io docs user quick start  installation    should work fine for following the guide on your local machine    An image registry that you can push images to  If you re using  kind    make sure your  KO DOCKER REPO  environment variable is set to    kind local     A publicly available git repository where you can put a pipeline yaml   file      Step 1  Install Tekton Pipelines and the Resolvers  See  the installation instructions for Tekton Pipeline    install md installing tekton pipelines on kubernetes   and  the installation instructions for the built in resolvers    install md installing and configuring remote task and pipeline resolution       Step 2  Ensure Pipelines is configured to enable resolvers  Starting with v0 41 0  remote resolvers for Tekton Pipelines are enabled by default   but can be disabled via feature flags in the  resolvers feature flags  configmap in  the  tekton pipelines resolvers  namespace  Check that configmap to verify that the resolvers you wish to have enabled are set to   true     The feature flags for the built in resolvers are     The  bundles  resolver   enable bundles resolver    The  git  resolver   enable git resolver    The  hub  resolver   enable hub resolver    The  cluster  resolver   enable cluster resolver      Step 3  Try it out   In order to test out your install you ll need a Pipeline stored in a public git repository  First cd into a clone of your repo and then create a new branch      sh   checkout a new branch in the public repo you re using git checkout  b add a simple pipeline      Then create a basic pipeline      sh cat    EOF    pipeline yaml kind  Pipeline apiVersion  tekton dev v1beta1 metadata    name  a simple pipeline spec    params      name  username   tasks      name  task 1     params        name  username       value    params username      taskSpec        params          name  username       steps          image  alpine 3 15         script              echo  hello   params username   EOF      Commit the pipeline and push it to your git repo      sh git add   pipeline yaml git commit  m  Add a basic pipeline to test Tekton Pipeline remote resolution     push to your publicly accessible repository  replacing origin with   your git remote s name git push origin add a simple pipeline      And finally create a  PipelineRun  that uses your pipeline      sh   first assign your public repo s url to an environment variable REPO URL   insert your repo s url here    create a pipelinerun yaml file cat   EOF   pipelinerun yaml kind  PipelineRun apiVersion  tekton dev v1beta1 metadata    name  run basic pipeline from git spec    pipelineRef      resolver  git     params        name  url       value    REPO URL        name  revision       value  add a simple pipeline       name  pathInRepo       value  pipeline yaml   params      name  username     value  liza EOF    execute the pipelinerun kubectl apply  f   pipelinerun yaml         Step 4  Monitor the PipelineRun  First let s watch the PipelineRun to see if it succeeds      sh kubectl get pipelineruns  w      Shortly the PipelineRun should move into a Succeeded state   Now we can check the logs of the PipelineRun s only task      sh kubectl logs run basic pipeline from git task 1 pod   This should print  hello liza            Except as otherwise noted  the content of this page is licensed under the  Creative Commons Attribution 4 0 License  https   creativecommons org licenses by 4 0    and code samples are licensed under the  Apache 2 0 License  https   www apache org licenses LICENSE 2 0


tekton weight 402 Tekton Bundle Contract v0 1 When using a Tekton Bundle in a task or pipeline reference the OCI artifact backing the Tekton Bundles Contract

Answer:
<!--
---
linkTitle: "Tekton Bundles Contract"
weight: 402
---
-->

# Tekton Bundle Contract v0.1

When using a Tekton Bundle in a task or pipeline reference, the OCI artifact backing the
bundle must adhere to the following contract.

## Contract

Only Tekton CRDs (eg, `Task` or `Pipeline`) may reside in a Tekton Bundle used as a Tekton
bundle reference.

Each layer of the image must map 1:1 with a single Tekton resource (eg Task).

*No more than 20* individual layers (Pipelines and/or Tasks) maybe placed in a single image.

Each layer must contain all of the following annotations:

- `dev.tekton.image.name` => `ObjectMeta.Name` of the resource
- `dev.tekton.image.kind` => `TypeMeta.Kind` of the resource, all lower-cased and singular (eg, `task`)
- `dev.tekton.image.apiVersion` => `TypeMeta.APIVersion` of the resource (eg
"tekton.dev/v1beta1")

The union of the { `dev.tekton.image.apiVersion`, `dev.tekton.image.kind`, `dev.tekton.image.name` }
annotations on a given layer must be unique among all layers of that image. In practical terms, this means no two
"tasks" can have the same name for example.

Each layer must be compressed and stored with a supported OCI MIME type *except* for `+zstd` types. For list of the
supported types see
<!-- wokeignore:rule=master -->
[the official spec](https://github.com/opencontainers/image-spec/blob/master/layer.md#zstd-media-types).

Furthermore, each layer must contain a YAML or JSON representation of the underlying resource. If the resource is
missing any identifying fields (missing an `apiVersion` for instance) then it will be considered invalid.

Any tool creating a Tekton bundle must enforce this format and ensure that the annotations and contents all match and
conform to this spec. Additionally, the Tekton controller will reject non-conforming Tekton Bundles.

## Examples

Say you wanted to create a Tekton Bundle out of the following resources:

```yaml
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: foo
---
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: bar
---
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: foobar
```

If we imagine what the contents of the resulting bundle look like, it would look something like this (YAML is just for
illustrative purposes):
```
# my-bundle
layers:
  - annotations:
    - name: "dev.tekton.image.name"
      value: "foo"
    - name: "dev.tekton.image.kind"
      value: "Task"
    - name: "dev.tekton.image.apiVersion"
      value: "tekton.dev/v1beta1"
    contents: <compressed bytes of Task object>
  - annotations:
    - name: "dev.tekton.image.name"
      value: "bar"
    - name: "dev.tekton.image.kind"
      value: "Task"
    - name: "dev.tekton.image.apiVersion"
      value: "tekton.dev/v1beta1"
    contents: <compressed bytes of Task object>
  - annotations:
    - name: "dev.tekton.image.name"
      value: "foobar"
    - name: "dev.tekton.image.kind"
      value: "Pipeline"
    - name: "dev.tekton.image.apiVersion"
      value: "tekton.dev/v1beta1"
    contents: <compressed bytes of Pipeline object>
```

---

Except as otherwise noted, the content of this page is licensed under the
[Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
and code samples are licensed under the
[Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).

linkTitle   Tekton Bundles Contract  weight  402            Tekton Bundle Contract v0 1  When using a Tekton Bundle in a task or pipeline reference  the OCI artifact backing the bundle must adhere to the following contract      Contract  Only Tekton CRDs  eg   Task  or  Pipeline   may reside in a Tekton Bundle used as a Tekton bundle reference   Each layer of the image must map 1 1 with a single Tekton resource  eg Task     No more than 20  individual layers  Pipelines and or Tasks  maybe placed in a single image   Each layer must contain all of the following annotations      dev tekton image name      ObjectMeta Name  of the resource    dev tekton image kind      TypeMeta Kind  of the resource  all lower cased and singular  eg   task      dev tekton image apiVersion      TypeMeta APIVersion  of the resource  eg   tekton dev v1beta1      The union of the    dev tekton image apiVersion    dev tekton image kind    dev tekton image name    annotations on a given layer must be unique among all layers of that image  In practical terms  this means no two  tasks  can have the same name for example   Each layer must be compressed and stored with a supported OCI MIME type  except  for   zstd  types  For list of the  supported types see       wokeignore rule master       the official spec  https   github com opencontainers image spec blob master layer md zstd media types     Furthermore  each layer must contain a YAML or JSON representation of the underlying resource  If the resource is  missing any identifying fields  missing an  apiVersion  for instance  then it will be considered invalid   Any tool creating a Tekton bundle must enforce this format and ensure that the annotations and contents all match and conform to this spec  Additionally  the Tekton controller will reject non conforming Tekton Bundles      Examples  Say you wanted to create a Tekton Bundle out of the following resources       yaml apiVersion  tekton dev v1beta1 kind  Task metadata    name  foo     apiVersion  tekton dev v1beta1 kind  Task metadata    name  bar     apiVersion  tekton dev v1beta1 kind  Pipeline metadata    name  foobar      If we imagine what the contents of the resulting bundle look like  it would look something like this  YAML is just for  illustrative purposes         my bundle layers      annotations        name   dev tekton image name        value   foo        name   dev tekton image kind        value   Task        name   dev tekton image apiVersion        value   tekton dev v1beta1      contents   compressed bytes of Task object      annotations        name   dev tekton image name        value   bar        name   dev tekton image kind        value   Task        name   dev tekton image apiVersion        value   tekton dev v1beta1      contents   compressed bytes of Task object      annotations        name   dev tekton image name        value   foobar        name   dev tekton image kind        value   Pipeline        name   dev tekton image apiVersion        value   tekton dev v1beta1      contents   compressed bytes of Pipeline object            Except as otherwise noted  the content of this page is licensed under the  Creative Commons Attribution 4 0 License  https   creativecommons org licenses by 4 0    and code samples are licensed under the  Apache 2 0 License  https   www apache org licenses LICENSE 2 0