Specifying remote pipelines and tasks using resolvers | Creating CI/CD pipelines

Specifying a remote pipeline, task, or step action from a Tekton catalog
- Configuring the hub resolver
- Specifying a remote pipeline, task, or step action using the hub resolver
Specifying a remote pipeline, task, or step action from a Tekton bundle
- Configuring the bundles resolver
- Specifying a remote pipeline, task, or step action using the bundles resolver
Specifying a remote pipeline, task, or step action with anonymous Git cloning
- Configuring the Git resolver for anonymous Git cloning
- Specifying a remote pipeline, task, or step action by using the Git resolver for anonymous cloning
Specifying a remote pipeline, task, or step action with an authenticated Git API
Specifying a remote pipeline, task, or step action by using the HTTP resolver
- Configuring the HTTP resolver
- Specifying a remote pipeline, task, or step action with the HTTP Resolver
Specifying a pipeline, task, or step action from the same cluster
- Configuring the cluster resolver
- Specifying a pipeline, task, or step action from the same cluster using the cluster resolver
Tasks provided in the OpenShift Pipelines namespace
Step action provided with OpenShift Pipelines
About non-versioned and versioned tasks and step actions
Additional resources

Pipelines and tasks are reusable blocks for your CI/CD processes. You can reuse pipelines or tasks that you previously developed, or that were developed by others, without having to copy and paste their definitions. These pipelines or tasks can be available from several types of sources, from other namespaces on your cluster to public catalogs.

In a pipeline run resource, you can specify a pipeline from an existing source. In a pipeline resource or a task run resource, you can specify a task from an existing source.

Step actions, defined in StepAction custom resources (CRs), are reusable actions that a single step within a task completes. When specifying a step, you can reference a StepAction definition from an existing source.

In these cases, the resolvers in Red Hat OpenShift Pipelines retrieve the pipeline, task, or StepAction definition from the specified source at run time.

The following resolvers are available in a default installaton of Red Hat OpenShift Pipelines:

Hub resolver: Retrieves a task, pipeline, or StepAction definition from the Pipelines Catalog available on Artifact Hub or Tekton Hub.
Bundles resolver: Retrieves a task, pipeline, or StepAction definition from a Tekton bundle, which is an OCI image available from any OCI repository, such as an OpenShift container repository.
Git resolver: Retrieves a task, pipeline, or StepAction definition from a Git repository. You must specify the repository, the branch, and the path.
HTTP resolver: Retrieves a task, pipeline, or StepAction definition from a remote HTTP or HTTPS URL. You must specify the URL for authentication.
Cluster resolver: Retrieves a task, pipeline, or StepAction definition that is already created on the same OpenShift Container Platform cluster in a specific namespace.

An OpenShift Pipelines installation includes a set of standard tasks that you can use in your pipelines. These tasks are located in the OpenShift Pipelines installation namespace, which is normally the openshift-pipelines namespace. You can use the cluster resolver to access the tasks.

OpenShift Pipelines also provides a standard StepAction definition. You can use the cluster resolver to access this definition.

Specifying a remote pipeline, task, or step action from a Tekton catalog

You can use the hub resolver to specify a remote pipeline, task, or StepAction definition that is defined either in a public Tekton catalog of Artifact Hub or in an instance of Tekton Hub.

The Artifact Hub project is not supported with Red Hat OpenShift Pipelines. Only the configuration of Artifact Hub is supported.

Configuring the hub resolver

You can change the default hub for pulling a resource, and the default catalog settings, by configuring the hub resolver.

Procedure

To edit the TektonConfig custom resource, enter the following command:
```
$ oc edit TektonConfig config
```

In the TektonConfig custom resource, edit the pipeline.hub-resolver-config spec:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    hub-resolver-config:
      default-tekton-hub-catalog: Tekton (1)
      default-artifact-hub-task-catalog: tekton-catalog-tasks (2)
      default-artifact-hub-pipeline-catalog: tekton-catalog-pipelines (3)
      defailt-kind: pipeline (4)
      default-type: tekton (5)
      tekton-hub-api: "https://my-custom-tekton-hub.example.com" (6)
      artifact-hub-api: "https://my-custom-artifact-hub.example.com" (7)

1	The default Tekton Hub catalog for pulling a resource.
2	The default Artifact Hub catalog for pulling a task resource.
3	The default Artifact Hub catalog for pulling a pipeline resource.
4	The default object kind for references.
5	The default hub for pulling a resource, either `artifact` for Artifact Hub or `tekton` for Tekton Hub.
6	The Tekton Hub API used, if the `default-type` option is set to `tekton`.
7	Optional: The Artifact Hub API used, if the `default-type` option is set to `artifact`.

If you set the default-type option to tekton, you must configure your own instance of the Tekton Hub by setting the tekton-hub-api value.

If you set the default-type option to artifact then the resolver uses the public hub API at https://artifacthub.io/ by default. You can configure your own Artifact Hub API by setting the artifact-hub-api value.

Specifying a remote pipeline, task, or step action using the hub resolver

When creating a pipeline run, you can specify a remote pipeline from Artifact Hub or Tekton Hub. When creating a pipeline or a task run, you can specify a remote task from Artifact Hub or Tekton Hub. When creating a step within a task, you can reference a remote StepAction definition from Artifact Hub or Tekton Hub.

Procedure

To specify a remote pipeline, task, or StepAction definition from Artifact Hub or Tekton Hub, use the following reference format in the pipelineRef, taskRef, or step.ref spec:

# ...
  resolver: hub
  params:
  - name: catalog
    value: <catalog>
  - name: type
    value: <catalog_type>
  - name: kind
    value: [pipeline|task]
  - name: name
    value: <resource_name>
  - name: version
    value: <resource_version>
# ...

Table 1. Supported parameters for the hub resolver
Parameter	Description	Example value
`catalog`	The catalog for pulling the resource.	Default: `tekton-catalog-tasks` (for the `task` kind); `tekton-catalog-pipelines` (for the `pipeline` kind).
`type`	The type of the catalog for pulling the resource. Either `artifact` for Artifact Hub or `tekton` for Tekton Hub.	Default: `artifact`
`kind`	Either `task` or `pipeline`.	Default: `task`
`name`	The name of the task or pipeline to fetch from the hub.	`golang-build`
`version`	The version of the task or pipeline to fetch from the hub. You must use quotes (`"`) around the number.	`"0.5.0"`

If the pipeline or task requires additional parameters, specify values for these parameters in the params section of the specification of the pipeline, pipeline run, or task run. The params section of the pipelineRef or taskRef specification must contain only the parameters that the resolver supports.

Examples

The following example pipeline run references a remote pipeline from a catalog:

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: hub-pipeline-reference-demo
spec:
  pipelineRef:
    resolver: hub
    params:
    - name: catalog
      value: tekton-catalog-pipelines
    - name: type
      value: artifact
    - name: kind
      value: pipeline
    - name: name
      value: example-pipeline
    - name: version
      value: "0.1"
  params:
  - name: sample-pipeline-parameter
    value: test

The following example pipeline references a remote task from a catalog:

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: pipeline-with-hub-task-reference-demo
spec:
  tasks:
  - name: "cluster-task-reference-demo"
    taskRef:
      resolver: hub
      params:
      - name: catalog
        value: tekton-catalog-tasks
      - name: type
        value: artifact
      - name: kind
        value: task
      - name: name
        value: example-task
      - name: version
        value: "0.6"
    params:
    - name: sample-task-parameter
      value: test

The following example task run references a remote task from a catalog:

apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  name: hub-task-reference-demo
spec:
  taskRef:
    resolver: hub
    params:
    - name: catalog
      value: tekton-catalog-tasks
    - name: type
      value: artifact
    - name: kind
      value: task
    - name: name
      value: example-task
    - name: version
      value: "0.6"
  params:
  - name: sample-task-parameter
    value: test

The following example task includes a step that references a StepAction definition from a catalog:

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: hub-stepaction-reference-demo
spec:
  steps:
  - name: example-step
    ref:
    - resolver: hub
    - params:
      - name: catalog
        value: tekton-catalog-stepactions
      - name: type
        value: artifact
      - name: kind
        value: StepAction
      - name: name
        value: example-stepaction
      - name: version
        value: "0.6"
    params:
    - name: sample-stepaction-parameter
      value: test

Specifying a remote pipeline, task, or step action from a Tekton bundle

You can use the bundles resolver to specify a remote pipeline, task, or StepAction definition from a Tekton bundle. A Tekton bundle is an OCI image available from any OCI repository, such as an OpenShift container repository.

Configuring the bundles resolver

You can change the default service account name and the default kind for pulling resources from a Tekton bundle by configuring the bundles resolver.

Procedure

To edit the TektonConfig custom resource, enter the following command:
```
$ oc edit TektonConfig config
```

In the TektonConfig custom resource, edit the pipeline.bundles-resolver-config spec:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    bundles-resolver-config:
      default-service-account: pipelines (1)
      default-kind: task (2)

1	The default service account name to use for bundle requests.
2	The default layer kind in the bundle image.

Specifying a remote pipeline, task, or step action using the bundles resolver

When creating a pipeline run, you can specify a remote pipeline from a Tekton bundle. When creating a pipeline or a task run, you can specify a remote task from a Tekton bundle. When creating a step within a task, you can reference a remote StepAction definition from a Tekton bundle.

Procedure

To specify a remote pipeline, task, or StepAction definition from a Tekton bundle, use the following reference format in the pipelineRef, taskRef, or step.ref spec:

# ...
  resolver: bundles
  params:
  - name: bundle
    value: <fully_qualified_image_name>
  - name: name
    value: <resource_name>
  - name: kind
    value: [pipeline|task]
# ...

Table 2. Supported parameters for the bundles resolver
Parameter	Description	Example value
`serviceAccount`	The name of the service account to use when constructing registry credentials.	`default`
`bundle`	The bundle URL pointing at the image to fetch.	`gcr.io/tekton-releases/catalog/upstream/golang-build:0.1`
`name`	The name of the resource to pull out of the bundle.	`golang-build`
`kind`	The kind of the resource to pull out of the bundle.	`task`

Examples

The following example pipeline run references a remote pipeline from a Tekton bundle:

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: bundle-pipeline-reference-demo
spec:
  pipelineRef:
    resolver: bundles
    params:
    - name: bundle
      value: registry.example.com:5000/simple/pipeline:latest
    - name: name
      value: hello-pipeline
    - name: kind
      value: pipeline
  params:
  - name: sample-pipeline-parameter
    value: test
  - name: username
    value: "pipelines"

The following example pipeline references a remote task from a Tekton bundle:

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: pipeline-with-bundle-task-reference-demo
spec:
  tasks:
  - name: "bundle-task-demo"
    taskRef:
      resolver: bundles
      params:
      - name: bundle
        value: registry.example.com:5000/advanced/task:latest
      - name: name
        value: hello-world
      - name: kind
        value: task
    params:
    - name: sample-task-parameter
      value: test

The following example task run references a remote task from a Tekton bundle:

apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  name: bundle-task-reference-demo
spec:
  taskRef:
    resolver: bundles
    params:
    - name: bundle
      value: registry.example.com:5000/simple/new_task:latest
    - name: name
      value: hello-world
    - name: kind
      value: task
  params:
  - name: sample-task-parameter
    value: test

The following example task includes a step that references a StepAction definition from a Tekton bundle:

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: bundle-stepaction-reference-demo
spec:
  steps:
  - name: example-step
    ref:
      resolver: bundles
      params:
      - name: bundle
        value: registry.example.com:5000/simple/new_task:latest
      - name: name
        value: hello-world-action
      - name: kind
        value: StepAction
    params:
    - name: sample-stepaction-parameter
      value: test

Specifying a remote pipeline, task, or step action with anonymous Git cloning

You can use the Git resolver to access a remote pipeline, task, or StepAction definition from a Git repository. The repository must include a YAML file that defines the pipeline or task. For anonymous access, you can clone repositories with the resolver without needing authentication credentials.

Configuring the Git resolver for anonymous Git cloning

If you want to use anonymous Git cloning, you can configure the default Git revision, fetch timeout, and default repository URL for pulling remote pipelines and tasks from a Git repository.

Procedure

To edit the TektonConfig custom resource, enter the following command:
```
$ oc edit TektonConfig config
```

In the TektonConfig custom resource, edit the pipeline.git-resolver-config spec:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    git-resolver-config:
      default-revision: main (1)
      fetch-timeout: 1m (2)
      default-url: https://github.com/tektoncd/catalog.git (3)

1	The default Git revision to use if none is specified.
2	The maximum time any single Git clone resolution may take, for example, `1m`, `2s`, `700ms`. Red Hat OpenShift Pipelines also enforces a global maximum timeout of 1 minute on all resolution requests.
3	The default Git repository URL for anonymous cloning if none is specified.

Specifying a remote pipeline, task, or step action by using the Git resolver for anonymous cloning

When creating a pipeline run, you can specify a remote pipeline from a Git repository by using anonymous cloning. When creating a pipeline or a task run, you can specify a remote task from a Git repository. When creating a step within a task, you can reference a remote StepAction definition from a Git repository.

Procedure

To specify a remote pipeline, task, or StepAction definition from a Git repository, use the following reference format in the pipelineRef, taskRef, or step.ref spec:

# ...
  resolver: git
  params:
  - name: url
    value: <git_repository_url>
  - name: revision
    value: <branch_name>
  - name: pathInRepo
    value: <path_in_repository>
# ...

Table 3. Supported parameters for the Git resolver
Parameter	Description	Example value
`url`	The URL of the repository, when using anonymous cloning.	`https://github.com/tektoncd/catalog.git`
`revision`	The Git revision in the repository. You can specify a branch name, a tag name, or a commit SHA hash.	`aeb957601cf41c012be462827053a21a420befca` `main` `v0.38.2`
`pathInRepo`	The path name of the YAML file in the repository.	`task/golang-build/0.3/golang-build.yaml`

To clone and fetch the repository anonymously, use the url parameter. Do not specify the url parameter and the repo parameter together.

If the pipeline or task requires additional parameters, provide these parameters in params.

Examples

The following example pipeline run references a remote pipeline from a Git repository:

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: git-pipeline-reference-demo
spec:
  pipelineRef:
    resolver: git
    params:
      - name: url
        value: https://github.com/tektoncd/catalog.git
      - name: revision
        value: main
      - name: pathInRepo
        value: pipeline/simple/0.1/simple.yaml
  params:
    - name: name
      value: "testPipelineRun"
    - name: sample-pipeline-parameter
      value: test

The following example pipeline references a remote task from a Git repository:

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: pipeline-with-git-task-reference-demo
spec:
  tasks:
    - name: "git-task-reference-demo"
      taskRef:
        resolver: git
        params:
          - name: url
            value: https://github.com/tektoncd/catalog.git
          - name: revision
            value: main
          - name: pathInRepo
            value: task/git-clone/0.6/git-clone.yaml
      params:
      - name: sample-task-parameter
        value: test

The following example task run references a remote task from a Git repository:

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: git-task-reference-demo
spec:
  taskRef:
    resolver: git
    params:
      - name: url
        value: https://github.com/tektoncd/catalog.git
      - name: revision
        value: main
      - name: pathInRepo
        value: task/git-clone/0.6/git-clone.yaml
  params:
  - name: sample-task-parameter
    value: test

The following example task includes a step that references a StepAction definition from a Git repository:

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: git-stepaction-reference-demo
spec:
  steps:
  - name: example-step
    ref:
      resolver: git
      - name: url
        value: https://github.com/openshift-pipelines/tektoncd-catalog.git
      - name: revision
        value: p
      - name: pathInRepo
        value: stepactions/stepaction-git-clone/0.4.1/stepaction-git-clone.yaml
    params:
    - name: sample-stepaction-parameter
      value: test

Specifying a remote pipeline, task, or step action with an authenticated Git API

You can specify a remote pipeline, task, or StepAction definition from a Git repository by using the Git resolver. The repository must contain a YAML file that defines the pipeline or task. You can securely access repositories by using an authenticated API, which supports user authentication.

Configuring the Git resolver for an authenticated API

For an authenticated Source Control Management (SCM) API, you must set the configuration for the authenticated Git connection.

You can use Git repository providers that are supported by the go-scm library. Not all go-scm implementations have been tested with the Git resolver, but the following providers are known to work:

github.com and GitHub Enterprise
gitlab.com and self-hosted Gitlab
Gitea
BitBucket Server
BitBucket Cloud

You can configure Git connections by using the authenticated SCM API. You can provide a security token that enables all users on your cluster to access one repository. Additionally, you can specify different SCM providers and tokens for specific pipelines or tasks.
If you configure the Git resolver to use the authenticated SCM API, you can also use anonymous Git clone references to retrieve pipelines and tasks.

Procedure

To edit the TektonConfig custom resource, enter the following command:
```
$ oc edit TektonConfig config
```

In the TektonConfig custom resource, edit the pipeline.git-resolver-config spec:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    git-resolver-config:
      default-revision: main (1)
      fetch-timeout: 1m (2)
      scm-type: github (3)
      server-url: api.internal-github.com (4)
      api-token-secret-name: github-auth-secret (5)
      api-token-secret-key: github-auth-key (6)
      api-token-secret-namespace: github-auth-namespace (7)
      default-org: tektoncd (8)

1	The default Git revision to use if none is specified.
2	The maximum time any single Git clone resolution may take, for example, `1m`, `2s`, `700ms`. Red Hat OpenShift Pipelines also enforces a global maximum timeout of 1 minute on all resolution requests.
3	The SCM provider type.
4	The base URL for use with the authenticated SCM API. This setting is not required if you are using `github.com`, `gitlab.com`, or BitBucket Cloud.
5	The name of the secret that contains the SCM provider API token.
6	The key within the token secret that contains the token.
7	The namespace containing the token secret, if not `default`.
8	Optional: The default organization for the repository, when using the authenticated API. This organization is used if you do not specify an organization in the resolver parameters.

The scm-type, api-token-secret-name, and api-token-secret-key settings are required to use the authenticated SCM API.

Configuring multiple Git providers

You can configure multiple Git providers, or you can add multiple configurations for the same Git provider, to use in different task runs and pipeline runs.

Add details in the TektonConfig custom resource (CR) with your unique identifier key prefix.

Procedure

Edit the TektonConfig CR by running the following command:
```
$ oc edit TektonConfig config
```

In the TektonConfig CR, edit the pipeline.git-resolver-config spec:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
# ...
  pipeline:
    git-resolver-config:
      # configuration 1 (1)
      fetch-timeout: "1m"
      default-url: "https://github.com/tektoncd/catalog.git"
      default-revision: "main"
      scm-type: "github"
      server-url: ""
      api-token-secret-name: ""
      api-token-secret-key: ""
      api-token-secret-namespace: "default"
      default-org: ""
      # configuration 2 (2)
      test1.fetch-timeout: "5m"
      test1.default-url: ""
      test1.default-revision: "stable"
      test1.scm-type: "github"
      test1.server-url: "api.internal-github.com"
      test1.api-token-secret-name: "test1-secret"
      test1.api-token-secret-key: "token"
      test1.api-token-secret-namespace: "test1"
      test1.default-org: "tektoncd"
      # configuration 3 (3)
      test2.fetch-timeout: "10m"
      test2.default-url: ""
      test2.default-revision: "stable"
      test2.scm-type: "gitlab"
      test2.server-url: "api.internal-gitlab.com"
      test2.api-token-secret-name: "test2-secret"
      test2.api-token-secret-key: "pat"
      test2.api-token-secret-namespace: "test2"
      test2.default-org: "tektoncd-infra"
# ...

1	The default configuration to use if no `configKey` key is provided or the key is provided with the `default` value.
2	The configuration used if the `configKey` key is passed with the `test1` value.
3	The configuration used if the `configKey` key is passed with the `test2` value.

configKey values with the . symbol are not supported. If you try to pass a configKey value that contains the . symbol, the TaskRun or PipelineRun resource where you passed the value fails to run.

Specifying a remote pipeline, task, or step action using the Git resolver with the authenticated SCM API

When creating a pipeline run, you can specify a remote pipeline from a Git repository using the authenticated SCM API. When creating a pipeline or a task run, you can specify a remote task from a Git repository. When creating a step within a task, you can reference a remote StepAction definition from a Git repository.

Prerequisites

If you want to use the authenticated SCM API, you must configure the authenticated Git connection for the Git resolver.

Procedure

To specify a remote pipeline, task, or StepAction definition from a Git repository, use the following reference format in the pipelineRef, taskRef, or step.ref spec:

# ...
  resolver: git
  params:
  - name: org
    value: <git_organization_name>
  - name: repo
    value: <git_repository_name>
  - name: revision
    value: <branch_name>
  - name: pathInRepo
    value: <path_in_repository>
# ...

Table 4. Supported parameters for the Git resolver
Parameter	Description	Example value
`org`	The organization for the repository, when using the authenticated SCM API.	`tektoncd`
`repo`	The repository name, when using the authenticated SCM API.	`test-infra`
`revision`	The Git revision in the repository. You can specify a branch name, a tag name, or a commit SHA hash.	`aeb957601cf41c012be462827053a21a420befca` `main` `v0.38.2`
`pathInRepo`	The path name of the YAML file in the repository.	`task/golang-build/0.3/golang-build.yaml`

To clone and fetch the repository anonymously, use the url parameter. To use the authenticated SCM API, use the repo parameter. Do not specify the url parameter and the repo parameter together.

Examples

The following example pipeline run references a remote pipeline from a Git repository:

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: git-pipeline-reference-demo
spec:
  pipelineRef:
    resolver: git
    params:
    - name: org
      value: tektoncd
    - name: repo
      value: catalog
    - name: revision
      value: main
    - name: pathInRepo
      value: pipeline/simple/0.1/simple.yaml
  params:
  - name: name
    value: "testPipelineRun"
  - name: sample-pipeline-parameter
    value: test

The following example pipeline references a remote task from a Git repository:

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: pipeline-with-git-task-reference-demo
spec:
  tasks:
  - name: "git-task-reference-demo"
    taskRef:
      resolver: git
      params:
      - name: org
        value: tektoncd
      - name: repo
        value: catalog
      - name: revision
        value: main
      - name: pathInRepo
        value: task/git-clone/0.6/git-clone.yaml
    params:
    - name: sample-task-parameter
      value: test

The following example task run references a remote task from a Git repository:

apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  name: git-task-reference-demo
spec:
  taskRef:
    resolver: git
    params:
    - name: org
      value: tektoncd
    - name: repo
      value: catalog
    - name: revision
      value: main
    - name: pathInRepo
      value: task/git-clone/0.6/git-clone.yaml
  params:
  - name: sample-task-parameter
    value: test

The following example task includes a step that references a StepAction definition from a Git repository:

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: git-stepaction-reference-demo
spec:
  steps:
  - name: example-step
    ref:
      resolver: git
      - name: org
        value: openshift-pipelines
      - name: repo
        value: tektoncd-catalog
      - name: revision
        value: p
      - name: pathInRepo
        value: stepactions/stepaction-git-clone/0.4.1/stepaction-git-clone.yaml
    params:
    - name: sample-stepaction-parameter
      value: test

Specifying multiple Git providers

You can specify multiple Git providers by passing the unique configKey parameter when creating TaskRun and PipelineRun resources.

If no configKey parameter is passed, the default configuration is used. You can also specify default configuration by setting the configKey value to default.

Prerequisites

Configure multiple Git providers through the Tektonconfig custom resource. For more information, see "Configuring multiple Git providers".

Procedure

To specify a Git provider, use the following reference format in the pipelineRef and taskRef spec:
```
# ...
  resolver: git
  params:
  # ...
  - name: configKey
    value: <your_unique_key> (1)
# ...
```
1 Your unique key that matches one of the configuration keys, for example, test1.

Specifying a remote pipeline or task by using the Git resolver with the authenticated SCM API overriding the Git resolver configuration

You can override the initial configuration settings in specific pipeline runs or tasks to customize the behavior according to different use cases. You can use this method to access an authenticated provider that is not configured in the TektonConfig custom resource (CR).

The following example task run references a remote task from a Git repository that overrides the previous resolver configuration:

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: git-task-reference-demo
spec:
  taskRef:
    resolver: git
    params:
    - name: org
      value: tektoncd
    - name: repo
      value: catalog
    - name: revision
      value: main
    - name: pathInRepo
      value: task/git-clone/0.6/git-clone.yaml
    - name: token
      value: my-secret-token
    - name: tokenKey
      value: token
    - name: scmType
      value: github
    - name: serverURL
      value: https://ghe.mycompany.com

Table 5. Supported parameters to override the Git resolver
Parameter	Description	Example value
`org`	The organization for the repository.	`tektoncd`
repo	The repository name.	catalog
revision	The Git revision in the repository. You can specify a branch name, a tag name, or a commit SHA hash.	main
pathInRepo	The path name of the YAML file in the repository.	task/git-clone/0.6/git-clone.yaml
token	The secret name used for authentication.	my-secret-token
tokenKey	The key name for the token.	token
scmType	The type of SCM (Source Control Management) system.	github
serverURL	The URL of the server hosting the repository.	`https://ghe.mycompany.com`

Specifying a remote pipeline, task, or step action by using the HTTP resolver

You can specify a remote pipeline, task, or StepAction definition from an HTTP or HTTPS URL by using the HTTP resolver. The URL must point to a YAML file that defines the pipeline, task, or step action.

Configuring the HTTP resolver

You can use the HTTP resolver to fetch pipelines or tasks from an HTTP or HTTPS URL. You can configure the default values for the HTTP resolver by editing the TektonConfig custom resource (CR).

Procedure

Edit the TektonConfig CR by entering the following command:
```
$ oc edit TektonConfig config
```

In the TektonConfig CR, edit the pipeline.http-resolver-config spec:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    http-resolver-config:
      fetch-timeout: "1m" (1)

1	The maximum amount of time the HTTP resolver waits for a response from the server.

Specifying a remote pipeline, task, or step action with the HTTP Resolver

When creating a pipeline run, you can specify a remote pipeline from an HTTP or HTTPS URL. When creating a pipeline or a task run, you can specify a remote task from an HTTP or HTTPS URL. When creating a step within a task, you can reference a remote StepAction definition from an HTTP or HTTPS URL.

Procedure

Specify a remote pipeline, task, or StepAction definition from an HTTP or HTTPS URL, using the following format in the pipelineRef, taskRef, or step.ref spec:

# ...
  resolver: http
  params:
  - name: url
    value: <fully_qualified_http_url>
# ...

Table 6. Supported parameters for the HTTP Resolver
Parameter	Description	Example Value
`url`	The HTTP URL pointing to the Tekton resource to fetch.	`https://raw.githubusercontent.com/openshift-pipelines/tektoncd-catalog/p/tasks/task-git-clone/0.4.1/task-git-clone.yaml`

Examples

The following example pipeline run references a remote pipeline from the same cluster:

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: http-pipeline-reference-demo
spec:
  pipelineRef:
    resolver: http
    params:
    - name: url
      value: https://raw.githubusercontent.com/tektoncd/catalog/main/pipeline/build-push-gke-deploy/0.1/build-push-gke-deploy.yaml
  params:
  - name: sample-pipeline-parameter
    value: test
  - name: username
    value: "pipelines"

The following example pipeline defines a task that references a remote task from an HTTPS URL:

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: pipeline-with-http-task-reference-demo
spec:
  tasks:
  - name: "http-task-demo"
    taskRef:
      resolver: http
      params:
      - name: url
        value: https://raw.githubusercontent.com/openshift-pipelines/tektoncd-catalog/p/tasks/task-git-clone/0.4.1/task-git-clone.yaml
    params:
    - name: sample-task-parameter
      value: test

The following example task run references a remote task from an HTTPS URL:

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: http-task-reference-demo
spec:
  taskRef:
    resolver: http
    params:
    - name: url
      value: https://raw.githubusercontent.com/openshift-pipelines/tektoncd-catalog/p/tasks/task-git-clone/0.4.1/task-git-clone.yaml
  params:
  - name: sample-task-parameter
    value: test

The following example task includes a step that references a StepAction definition from an HTTPS URL:

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: http-stepaction-reference-demo
spec:
  steps:
  - name: example-step
    ref:
      resolver: http
      params:
      - name: url
        value: https://raw.githubusercontent.com/openshift-pipelines/tektoncd-catalog/p/stepactions/stepaction-git-clone/0.4.1/stepaction-git-clone.yaml
    params:
    - name: sample-stepaction-parameter
      value: test

Specifying a pipeline, task, or step action from the same cluster

You can use the cluster resolver to specify a pipeline, task, or StepAction definition that is defined in a namespace on the OpenShift Container Platform cluster where Red Hat OpenShift Pipelines is running.

In particular, you can use the cluster resolver to access tasks that OpenShift Pipelines provides in its installation namespace, which is normally the openshift-pipelines namespace.

Configuring the cluster resolver

You can change the default kind and namespace for the cluster resolver, or limit the namespaces that the cluster resolver can use.

Procedure

To edit the TektonConfig custom resource, enter the following command:
```
$ oc edit TektonConfig config
```

In the TektonConfig custom resource, edit the pipeline.cluster-resolver-config spec:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    cluster-resolver-config:
      default-kind: pipeline (1)
      default-namespace: namespace1 (2)
      allowed-namespaces: namespace1, namespace2 (3)
      blocked-namespaces: namespace3, namespace4 (4)

1	The default resource kind to fetch, if not specified in parameters.
2	The default namespace for fetching resources, if not specified in parameters.
3	A comma-separated list of namespaces that the resolver is allowed to access. If this key is not defined, all namespaces are allowed.
4	An optional comma-separated list of namespaces which the resolver is blocked from accessing. If this key is not defined, all namespaces are allowed.

Specifying a pipeline, task, or step action from the same cluster using the cluster resolver

When creating a pipeline run, you can specify a pipeline that exists on the same cluster. When creating a pipeline or a task run, you can specify a task that exists on the the same cluster. When creating a step within a task, you can specify a StepAction definition that exists on the the same cluster.

Procedure

To specify a pipeline, task, or StepAction definition from the same cluster, use the following reference format in the pipelineRef, taskRef, or step.ref spec:

# ...
  resolver: cluster
  params:
  - name: name
    value: <name>
  - name: namespace
    value: <namespace>
  - name: kind
    value: [pipeline|task|stepaction]
# ...

Table 7. Supported parameters for the cluster resolver
Parameter	Description	Example value
`name`	The name of the resource to fetch.	`some-pipeline`
`namespace`	The namespace in the cluster containing the resource.	`other-namespace`
`kind`	The kind of the resource to fetch.	`pipeline`

If the pipeline or task requires additional parameters, provide these parameters in params.

Examples

The following example pipeline run references a pipeline from the same cluster:

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: cluster-pipeline-reference-demo
spec:
  pipelineRef:
    resolver: cluster
    params:
    - name: name
      value: some-pipeline
    - name: namespace
      value: test-namespace
    - name: kind
      value: pipeline
  params:
  - name: sample-pipeline-parameter
    value: test

The following example pipeline references a task from the same cluster:

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: pipeline-with-cluster-task-reference-demo
spec:
  tasks:
  - name: "cluster-task-reference-demo"
    taskRef:
      resolver: cluster
      params:
      - name: name
        value: some-task
      - name: namespace
        value: test-namespace
      - name: kind
        value: task
    params:
    - name: sample-task-parameter
      value: test

The following example task run references a task from the same cluster:

apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  name: cluster-task-reference-demo
spec:
  taskRef:
    resolver: cluster
    params:
    - name: name
      value: some-task
    - name: namespace
      value: test-namespace
    - name: kind
      value: task
  params:
  - name: sample-task-parameter
    value: test

The following example task includes a step that references a StepAction definition from the same cluster:

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: cluster-stepaction-reference-demo
spec:
  steps:
  - name: example-step
    ref:
      resolver: cluster
      params:
      - name: name
        value: some-step
      - name: namespace
        value: test-namespace
      - name: kind
        value: stepaction
  params:
  - name: sample-stepaction-parameter
    value: test

Tasks provided in the OpenShift Pipelines namespace

Until version 1.16, OpenShift Pipelines included ClusterTask functionality. Versions 1.17 and later no longer include this functionality. If your pipelines use ClusterTask references, you can re-create them with the tasks that are available from the OpenShift Pipelines installation namespace by using the cluster resolver. However, certain changes are made in these tasks compared to the previously existing ClusterTask definitions.

You cannot specify a custom execution image in any of the tasks available in the OpenShift Pipelines installation namespace. These tasks do not support parameters such as BUILDER_IMAGE, gitInitImage, or KN_IMAGE. If you want to use a custom execution image, create a copy of the task and replace the image by editing the copy.

buildah

The buildah task builds a source code tree into a container image and then pushes the image to a container registry.

Example usage of the buildah task

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: build-and-deploy
spec:
# ...
  tasks:
# ...
  - name: build-image
    taskRef:
      resolver: cluster
      params:
      - name: kind
        value: task
      - name: name
        value: buildah
      - name: namespace
        value: openshift-pipelines
    params:
    - name: IMAGE
      value: $(params.IMAGE)
    workspaces:
    - name: source
      workspace: shared-workspace
# ...

Table 8. Supported parameters for the `buildah` task
Parameter	Description	Type	Default value
`IMAGE`	Fully qualified container image name to be built by Buildah.	`string`
`DOCKERFILE`	Path to the `Dockerfile` (or `Containerfile`) relative to the `source` workspace.	`string`	`./Dockerfile`
`CONTEXT`	Path to the directory to use as the context.	`string`	`.`
`STORAGE_DRIVER`	Set the Buildah storage driver to reflect the settings of the current cluster node settings.	`string`	`vfs`
`FORMAT`	The format of the container to build, either `oci` or `docker`.	`string`	`oci`
`BUILD_EXTRA_ARGS`	Extra parameters for the `build` command when building the image.	`string`
`PUSH_EXTRA_ARGS`	Extra parameters for the `push` command when pushing the image.	`string`
`SKIP_PUSH`	Skip pushing the image to the container registry.	`string`	`false`
`TLS_VERIFY`	The TLS verification flag, normally `true`.	`string`	`true`
`VERBOSE`	Turn on verbose logging; all commands executed are added to the log.	`string`	`false`

Table 9. Supported workspaces for the `buildah` task
Workspace	Description
`source`	Container build context, usually the application source code that includes a `Dockerfile` or `Containerfile` file.
`dockerconfig`	An optional workspace for providing a `.docker/config.json` file that Buildah uses to access the container registry. Place the file at the root of the workspace with the name `config.json` or `.dockerconfigjson`.
`rhel-entitlement`	An optional workspace for providing the entitlement keys that Buildah uses to access a Red Hat Enterprise Linux (RHEL) subscription. The mounted workspace must contains the `entitlement.pem` and `entitlement-key.pem` files.

Table 10. Results that the `buildah` task returns
Result	Type	Description
`IMAGE_URL`	`string`	The fully qualified name of the image that was built.
`IMAGE_DIGEST`	`string`	Digest of the image that was built.

Changes from the buildah ClusterTask

The VERBOSE parameter was added.
The BUILDER_IMAGE parameter was removed.

git-cli

The git-cli task runs the git command-line utility. You can pass the full Git command or several commands to run using the GIT_SCRIPT parameter. If the commands need authentication to a Git repository, for example, in order to complete a push, you must supply the authentication credentials.

Example usage of the git-cli task

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: update-repo
spec:
# ...
  tasks:
# ...
  - name: push-to-repo
    taskRef:
      resolver: cluster
      params:
      - name: kind
        value: task
      - name: name
        value: git-cli
      - name: namespace
        value: openshift-pipelines
    params:
    - name: GIT_SCRIPT
      value: "git push"
    - name: GIT_USER_NAME
      value: "Example Developer"
    - name: GIT_USER_EMAIL
      value: "developer@example.com"
    workspaces:
    - name: ssh-directory
      workspace: ssh-workspace (1)
    - name: source
      workspace: shared-workspace
# ...

1	In this example, `ssh-workspace` must contain the contents of the `.ssh` directory with a valid key for authorization to the Git repository.

Table 11. Supported parameters for the `git-cli` task
Parameter	Description	Type	Default value
`CRT_FILENAME`	Certificate Authority (CA) bundle filename in the `ssl-ca-directory` workspace.	`string`	`ca-bundle.crt`
`HTTP_PROXY`	HTTP proxy server (non-TLS requests).	`string`
`HTTPS_PROXY`	HTTPS proxy server (TLS requests).	`string`
`NO_PROXY`	Opt out of proxying HTTP/HTTPS requests.	`string`
`SUBDIRECTORY`	Relative path to the `source` workspace where the git repository is present.	`string`
`USER_HOME`	Absolute path to the Git user home directory in the pod.	`string`	`/home/git`
`DELETE_EXISTING`	Erase any existing contents of the `source` workspace before completing the git operations.	`string`	`true`
`VERBOSE`	Log all the executed commands.	`string`	`false`
`SSL_VERIFY`	The global `http.sslVerify` value. Do not use `false` unless you trust the remote repository.	`string`	`true`
`GIT_USER_NAME`	Git user name for performing Git operations.	`string`
`GIT_USER_EMAIL`	Git user email for performing Git operations.	`string`
`GIT_SCRIPT`	The Git script to run.	`string`	`git help`

Table 12. Supported workspaces for the `git-cli` task
Workspace	Description
`ssh-directory`	A `.ssh` directory with the private key, `known_hosts`, `config`, and other files as necessary. If you provide this workspace, the task uses it for authentication to the Git repository. Bind this workspace to a `Secret` resource for secure storage of authentication information.
`basic-auth`	A workspace containing a `.gitconfig` and `.git-credentials` files. If you provide this workspace, the task uses it for authentication to the Git repository. Use a `ssh-directory` workspace for authentication instead of `basic-auth` whenever possible. Bind this workspace to a `Secret` resource for secure storage of authentication information.
`ssl-ca-directory`	A workspace containing CA certificates. If you provide this workspace, Git uses these certificates to verify the peer when interacting with remote repositories using HTTPS.
`source`	A workspace that contains the fetched Git repository.
`input`	An optional workspace that contains the files that need to be added to the Git repository. You can access the workspace from your script using `$(workspaces.input.path)`, for example: `cp $(workspaces.input.path)/<file_that_i_want> .` `git add <file_that_i_want>`

Table 13. Results that the `git-cli` task returns
Result	Type	Description
`COMMIT`	`string`	The SHA digest of the commit that is at the HEAD of the current branch in the cloned Git repository.

Changes from the git-cli ClusterTask

Several new parameters were added.
The BASE_IMAGE parameter was removed.
The ssl-ca-directory workspace was added.
The default values for the USER_HOME and VERBOSE parameters were changed.
The name of the result was changed from commit to COMMIT.

git-clone

The git-clone task uses Git to initialize and clone a remote repository on a workspace. You can use this task at the start of a pipeline that builds or otherwise processes this source code.

Example usage of the git-clone task

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: build-source
spec:
# ...
  tasks:
  - name: clone-repo
    taskRef:
      resolver: cluster
      params:
      - name: kind
        value: task
      - name: name
        value: git-clone
      - name: namespace
        value: openshift-pipelines
    params:
    - name: URL
      value: "https://github.com/example/repo.git"
    workspaces:
    - name: output
      workspace: shared-workspace

Table 14. Supported parameters for the `git-clone` task
Parameter	Description	Type	Default value
`CRT_FILENAME`	Certificate Authority (CA) bundle filename in the `ssl-ca-directory` workspace.	`string`	`ca-bundle.crt`
`HTTP_PROXY`	HTTP proxy server (non-TLS requests).	`string`
`HTTPS_PROXY`	HTTPS proxy server (TLS requests).	`string`
`NO_PROXY`	Opt out of proxying HTTP/HTTPS requests.	`string`
`SUBDIRECTORY`	Relative path in the `output` workspace where the task places the Git repository.	`string`
`USER_HOME`	Absolute path to the Git user home directory in the pod.	`string`	`/home/git`
`DELETE_EXISTING`	Delete the contents of the default workspace, if they exist, before running the Git operations.	`string`	`true`
`VERBOSE`	Log the executed commands.	`string`	`false`
`SSL_VERIFY`	The global `http.sslVerify` value. Do not set this parameter to to `false` unless you trust the remote repository.	`string`	`true`
`URL`	Git repository URL.	`string`
`REVISION`	The revision to check out, for example, a branch or tag.	`string`	`main`
`REFSPEC`	The `refspec` string for the repository that the task fetches before checking out the revision.	`string`
`SUBMODULES`	Initialize and fetch Git submodules.	`string`	`true`
`DEPTH`	Number of commits to fetch, a "shallow clone" is a single commit.	`string`	`1`
`SPARSE_CHECKOUT_DIRECTORIES`	List of directory patterns, separated by commas, for performing a "sparse checkout".	`string`

Table 15. Supported workspaces for the `git-clone` task
Workspace	Description
`ssh-directory`	A `.ssh` directory with the private key, `known_hosts`, `config`, and other files as necessary. If you provide this workspace, the task uses it for authentication to the Git repository. Bind this workspace to a `Secret` resource for secure storage of authentication information.
`basic-auth`	A workspace containing a `.gitconfig` and `.git-credentials` files. If you provide this workspace, the task uses it for authentication to the Git repository. Use a `ssh-directory` workspace for authentication instead of `basic-auth` whenever possible. Bind this workspace to a `Secret` resource for secure storage of authentication information.
`ssl-ca-directory`	A workspace containing CA certificates. If you provide this workspace, Git uses these certificates to verify the peer when interacting with remote repositories using HTTPS.
`output`	A workspace that contains the fetched git repository, data will be placed on the root of the workspace or on the relative path defined by the `SUBDIRECTORY` parameter.

Table 16. Results that the `git-clone` task returns
Result	Type	Description
`COMMIT`	`string`	The SHA digest of the commit that is at the HEAD of the current branch in the cloned Git repository.
`URL`	`string`	The URL of the repository that was cloned.
`COMMITTER_DATE`	`string`	The epoch timestamp of the commit that is at the HEAD of the current branch in the cloned Git repository.

Changes from the git-clone ClusterTask

All parameter names were changed to uppercase.
All result names were changed to uppercase.
The gitInitImage parameter was removed.

kn

The kn task uses the kn command-line utility to complete operations on Knative resources, such as services, revisions, or routes.

Example usage of the kn task

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
 name: kn-run
spec:
 pipelineSpec:
   tasks:
   - name: kn-run
     taskRef:
       resolver: cluster
       params:
       - name: kind
         value: task
       - name: name
         value: kn
       - name: namespace
         value: openshift-pipelines
     params:
     - name: ARGS
       value: [version]

Table 17. Supported parameters for the `kn` task
Parameter	Description	Type	Default value
`ARGS`	The arguments for the `kn` utility.	`array`	`- help`

Changes from the kn ClusterTask

The KN_IMAGE parameter was removed.

kn-apply

The kn-apply task deploys a specified image to a Knative Service. This task uses the kn service apply command to create or update the specified Knative service.

Example usage of the kn-apply task

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
 name: kn-apply-run
spec:
 pipelineSpec:
   tasks:
   - name: kn-apply-run
     taskRef:
       resolver: cluster
       params:
       - name: kind
         value: task
       - name: name
         value: kn-apply
       - name: namespace
         value: openshift-pipelines
     params:
     - name: SERVICE
       value: "hello"
     - name: IMAGE
       value: "gcr.io/knative-samples/helloworld-go:latest"

Table 18. Supported parameters for the `kn-apply` task
Parameter	Description	Type	Default value
`SERVICE`	The Knative service name.	`string`
`IMAGE`	The fully qualified name of the image to deploy.	`string`

Changes from the kn-apply ClusterTask

The KN_IMAGE parameter was removed.

maven

The maven task runs a Maven build.

Example usage of the maven task

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: build-and-deploy
spec:
# ...
  tasks:
# ...
  - name: build-from-source
    taskRef:
      resolver: cluster
      params:
      - name: kind
        value: task
      - name: name
        value: maven
      - name: namespace
        value: openshift-pipelines
    workspaces:
    - name: source
      workspace: shared-workspace
# ...

Table 19. Supported parameters for the `maven` task
Parameter	Description	Type	Default value
`GOALS`	The Maven goals to run.	`array`	`- package`
`MAVEN_MIRROR_URL`	The Maven repository mirror URL.	`string`
`SUBDIRECTORY`	The subdirectory within the `source` workspace that the task runs the Maven build on.	`string`	`.`

Table 20. Supported workspaces for the `maven` task
Workspace	Description
`source`	The workspace that contains the Maven project.
`server_secret`	The workspace that contains the secrets for connecting to the Maven server, such as the user name and password.
`proxy_secret`	The workspace that contains the credentials for connecting to the proxy server, such as the user name and password.
`proxy_configmap`	The workspace that contains proxy configuration values, such as `proxy_port`, `proxy_host`, `proxy_protocol`, `proxy_non_proxy_hosts`.
`maven_settings`	The workspace that contains custom Maven settings.

Changes from the maven ClusterTask

The parameter name CONTEXT_DIR was changed to SUBDIRECTORY.
The workspace name maven-settings was changed to maven_settings.

openshift-client

The openshift-client task runs commands using the oc command-line interface. You can use this task to manage an OpenShift Container Platform cluster.

Example usage of the openshift-client task

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
 name: openshift-client-run
spec:
 pipelineSpec:
   tasks:
   - name: openshift-client-run
     taskRef:
       resolver: cluster
       params:
       - name: kind
         value: task
       - name: name
         value: openshift-client
       - name: namespace
         value: openshift-pipelines
     params:
     - name: SCRIPT
       value: "oc version"

Table 21. Supported parameters for the `openshift-client` task
Parameter	Description	Type	Default value
`SCRIPT`	The `oc` CLI arguments to run.	`string`	`oc help`
`VERSION`	The OpenShift Container Platform version to use.	`string`	`latest`

Table 22. Supported workspaces for the `openshift-client` task
Workspace	Description
`manifest_dir`	The workspace containing manifest files that you want to apply using the `oc` utility.
`kubeconfig_dir`	An optional workspace in which you can provide a `.kube/config` file that contains credentials for accessing the cluster. Place this file at the root of the workspace and name it `kubeconfig`.

Changes from the openshift-client ClusterTask

The workspace name manifest-dir was changed to manifest_dir.
The workspace name kubeconfig-dir was changed to kubeconfig_dir.

s2i-dotnet

The s2i-dotnet task builds the source code using the Source to Image (S2I) dotnet builder image, which is available from the OpenShift Container Platform registry as image-registry.openshift-image-registry.svc:5000/openshift/dotnet.

Example usage of the s2i-dotnet task

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: build-and-deploy
spec:
# ...
  tasks:
# ...
  - name: build-s2i
    taskRef:
      resolver: cluster
      params:
      - name: kind
        value: task
      - name: name
        value: s2i-dotnet
      - name: namespace
        value: openshift-pipelines
    workspaces:
    - name: source
      workspace: shared-workspace
# ...

Table 23. Supported parameters for the `s2i-dotnet` task
Parameter	Description	Type	Default value
`IMAGE`	The fully qualified name for the container image that the S2I process builds.	`string`
`IMAGE_SCRIPTS_URL`	The URL containing the default assemble and run scripts for the builder image.	`string`	`image:///usr/libexec/s2i`
`ENV_VARS`	An array of values for environment variables to set in the build process, listed in the `KEY=VALUE` format.	`array`
`CONTEXT`	Path to the directory within the `source` workspace to use as the context.	`string`	`.`
`STORAGE_DRIVER`	Set the Buildah storage driver to reflect the settings of the current cluster node settings.	`string`	`vfs`
`FORMAT`	The format of the container to build, either `oci` or `docker`.	`string`	`oci`
`BUILD_EXTRA_ARGS`	Extra parameters for the `build` command when building the image.	`string`
`PUSH_EXTRA_ARGS`	Extra parameters for the `push` command when pushing the image.	`string`
`SKIP_PUSH`	Skip pushing the image to the container registry.	`string`	`false`
`TLS_VERIFY`	The TLS verification flag, normally `true`.	`string`	`true`
`VERBOSE`	Turn on verbose logging; all commands executed are added to the log.	`string`	`false`
`VERSION`	The tag of the image stream, which corresponds to the language version.	`string`	`latest`

Table 24. Supported workspaces for the `s2i-dotnet` task
Workspace	Description
`source`	The application source code, which is the build context for the S2I workflow.
`dockerconfig`	An optional workspace for providing a `.docker/config.json` file that Buildah uses to access the container registry. Place the file at the root of the workspace with the name `config.json` or `.dockerconfigjson`.

Table 25. Results that the `s2i-dotnet` task returns
Result	Type	Description
`IMAGE_URL`	`string`	The fully qualified name of the image that was built.
`IMAGE_DIGEST`	`string`	Digest of the image that was built.

s2i-go

The s2i-go task builds the source code using the S2I Golang builder image, which is available from the OpenShift Container Platform registry as image-registry.openshift-image-registry.svc:5000/openshift/golang.

Example usage of the s2i-go task

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: build-and-deploy
spec:
# ...
  tasks:
# ...
  - name: build-s2i
    taskRef:
      resolver: cluster
      params:
      - name: kind
        value: task
      - name: name
        value: s2i-go
      - name: namespace
        value: openshift-pipelines
    workspaces:
    - name: source
      workspace: shared-workspace
# ...

Table 26. Supported parameters for the `s2i-go` task
Parameter	Description	Type	Default value
`IMAGE`	The fully qualified name for the container image that the S2I process builds.	`string`
`IMAGE_SCRIPTS_URL`	The URL containing the default assemble and run scripts for the builder image.	`string`	`image:///usr/libexec/s2i`
`ENV_VARS`	An array of values for environment variables to set in the build process, listed in the `KEY=VALUE` format.	`array`
`CONTEXT`	Path to the directory within the `source` workspace to use as the context.	`string`	`.`
`STORAGE_DRIVER`	Set the Buildah storage driver to reflect the settings of the current cluster node settings.	`string`	`vfs`
`FORMAT`	The format of the container to build, either `oci` or `docker`.	`string`	`oci`
`BUILD_EXTRA_ARGS`	Extra parameters for the `build` command when building the image.	`string`
`PUSH_EXTRA_ARGS`	Extra parameters for the `push` command when pushing the image.	`string`
`SKIP_PUSH`	Skip pushing the image to the container registry.	`string`	`false`
`TLS_VERIFY`	The TLS verification flag, normally `true`.	`string`	`true`
`VERBOSE`	Turn on verbose logging; all commands executed are added to the log.	`string`	`false`
`VERSION`	The tag of the image stream, which corresponds to the language version.	`string`	`latest`

Table 27. Supported workspaces for the `s2i-go` task
Workspace	Description
`source`	The application source code, which is the build context for the S2I workflow.
`dockerconfig`	An optional workspace for providing a `.docker/config.json` file that Buildah uses to access the container registry. Place the file at the root of the workspace with the name `config.json` or `.dockerconfigjson`.

Table 28. Results that the `s2i-go` task returns
Result	Type	Description
`IMAGE_URL`	`string`	The fully qualified name of the image that was built.
`IMAGE_DIGEST`	`string`	Digest of the image that was built.

s2i-java

The s2i-java task builds the source code using the S2I Java builder image, which is available from the OpenShift Container Platform registry as image-registry.openshift-image-registry.svc:5000/openshift/java.

Table 29. Supported parameters for the `s2i-java` task
Parameter	Description	Type	Default value
`IMAGE`	The fully qualified name for the container image that the S2I process builds.	`string`
`IMAGE_SCRIPTS_URL`	The URL containing the default assemble and run scripts for the builder image.	`string`	`image:///usr/libexec/s2i`
`ENV_VARS`	An array of values for environment variables to set in the build process, listed in the `KEY=VALUE` format.	`array`
`CONTEXT`	Path to the directory within the `source` workspace to use as the context.	`string`	`.`
`STORAGE_DRIVER`	Set the Buildah storage driver to reflect the settings of the current cluster node settings.	`string`	`vfs`
`FORMAT`	The format of the container to build, either `oci` or `docker`.	`string`	`oci`
`BUILD_EXTRA_ARGS`	Extra parameters for the `build` command when building the image.	`string`
`PUSH_EXTRA_ARGS`	Extra parameters for the `push` command when pushing the image.	`string`
`SKIP_PUSH`	Skip pushing the image to the container registry.	`string`	`false`
`TLS_VERIFY`	The TLS verification flag, normally `true`.	`string`	`true`
`VERBOSE`	Turn on verbose logging; all commands executed are added to the log.	`string`	`false`
`VERSION`	The tag of the image stream, which corresponds to the language version.	`string`	`latest`

Table 30. Supported workspaces for the `s2i-java` task
Workspace	Description
`source`	The application source code, which is the build context for the S2I workflow.
`dockerconfig`	An optional workspace for providing a `.docker/config.json` file that Buildah uses to access the container registry. Place the file at the root of the workspace with the name `config.json` or `.dockerconfigjson`.

Table 31. Results that the `s2i-java` task returns
Result	Type	Description
`IMAGE_URL`	`string`	The fully qualified name of the image that was built.
`IMAGE_DIGEST`	`string`	Digest of the image that was built.

Changes from the s2i-java ClusterTask

Several new parameters were added.
The BUILDER_IMAGE, MAVEN_ARGS_APPEND, MAVEN_CLEAR_REPO, and MAVEN_MIRROR_URL parameters were removed. You can pass the MAVEN_ARGS_APPEND, MAVEN_CLEAR_REPO, and MAVEN_MIRROR_URL values as environment variables.
The parameter name PATH_CONTEXT was changed to CONTEXT.
The parameter name TLS_VERIFY was changed to TLSVERIFY.
The IMAGE_URL result was added.

s2i-nodejs

The s2i-nodejs task builds the source code using the S2I NodeJS builder image, which is available from the OpenShift Container Platform registry as image-registry.openshift-image-registry.svc:5000/openshift/nodejs.

Example usage of the s2i-nodejs task

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: build-and-deploy
spec:
# ...
  tasks:
# ...
  - name: build-s2i
    taskRef:
      resolver: cluster
      params:
      - name: kind
        value: task
      - name: name
        value: s2i-nodejs
      - name: namespace
        value: openshift-pipelines
    workspaces:
    - name: source
      workspace: shared-workspace
# ...

Table 32. Supported parameters for the `s2i-nodejs` task
Parameter	Description	Type	Default value
`IMAGE`	The fully qualified name for the container image that the S2I process builds.	`string`
`IMAGE_SCRIPTS_URL`	The URL containing the default assemble and run scripts for the builder image.	`string`	`image:///usr/libexec/s2i`
`ENV_VARS`	An array of values for environment variables to set in the build process, listed in the `KEY=VALUE` format.	`array`
`CONTEXT`	Path to the directory within the `source` workspace to use as the context.	`string`	`.`
`STORAGE_DRIVER`	Set the Buildah storage driver to reflect the settings of the current cluster node settings.	`string`	`vfs`
`FORMAT`	The format of the container to build, either `oci` or `docker`.	`string`	`oci`
`BUILD_EXTRA_ARGS`	Extra parameters for the `build` command when building the image.	`string`
`PUSH_EXTRA_ARGS`	Extra parameters for the `push` command when pushing the image.	`string`
`SKIP_PUSH`	Skip pushing the image to the container registry.	`string`	`false`
`TLS_VERIFY`	The TLS verification flag, normally `true`.	`string`	`true`
`VERBOSE`	Turn on verbose logging; all commands executed are added to the log.	`string`	`false`
`VERSION`	The tag of the image stream, which corresponds to the language version.	`string`	`latest`

Table 33. Supported workspaces for the `s2i-nodejs` task
Workspace	Description
`source`	The application source code, which is the build context for the S2I workflow.
`dockerconfig`	An optional workspace for providing a `.docker/config.json` file that Buildah uses to access the container registry. Place the file at the root of the workspace with the name `config.json` or `.dockerconfigjson`.

Table 34. Results that the `s2i-nodejs` task returns
Result	Type	Description
`IMAGE_URL`	`string`	The fully qualified name of the image that was built.
`IMAGE_DIGEST`	`string`	Digest of the image that was built.

s2i-perl

The s2i-perl task builds the source code using the S2I Perl builder image, which is available from the OpenShift Container Platform registry as image-registry.openshift-image-registry.svc:5000/openshift/perl.

Example usage of the s2i-perl task

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: build-and-deploy
spec:
# ...
  tasks:
# ...
  - name: build-s2i
    taskRef:
      resolver: cluster
      params:
      - name: kind
        value: task
      - name: name
        value: s2i-perl
      - name: namespace
        value: openshift-pipelines
    workspaces:
    - name: source
      workspace: shared-workspace
# ...

Table 35. Supported parameters for the `s2i-perl` task
Parameter	Description	Type	Default value
`IMAGE`	The fully qualified name for the container image that the S2I process builds.	`string`
`IMAGE_SCRIPTS_URL`	The URL containing the default assemble and run scripts for the builder image.	`string`	`image:///usr/libexec/s2i`
`ENV_VARS`	An array of values for environment variables to set in the build process, listed in the `KEY=VALUE` format.	`array`
`CONTEXT`	Path to the directory within the `source` workspace to use as the context.	`string`	`.`
`STORAGE_DRIVER`	Set the Buildah storage driver to reflect the settings of the current cluster node settings.	`string`	`vfs`
`FORMAT`	The format of the container to build, either `oci` or `docker`.	`string`	`oci`
`BUILD_EXTRA_ARGS`	Extra parameters for the `build` command when building the image.	`string`
`PUSH_EXTRA_ARGS`	Extra parameters for the `push` command when pushing the image.	`string`
`SKIP_PUSH`	Skip pushing the image to the container registry.	`string`	`false`
`TLS_VERIFY`	The TLS verification flag, normally `true`.	`string`	`true`
`VERBOSE`	Turn on verbose logging; all commands executed are added to the log.	`string`	`false`
`VERSION`	The tag of the image stream, which corresponds to the language version.	`string`	`latest`

Table 36. Supported workspaces for the `s2i-perl` task
Workspace	Description
`source`	The application source code, which is the build context for the S2I workflow.
`dockerconfig`	An optional workspace for providing a `.docker/config.json` file that Buildah uses to access the container registry. Place the file at the root of the workspace with the name `config.json` or `.dockerconfigjson`.

Table 37. Results that the `s2i-perl` task returns
Result	Type	Description
`IMAGE_URL`	`string`	The fully qualified name of the image that was built.
`IMAGE_DIGEST`	`string`	Digest of the image that was built.

s2i-php

The s2i-php task builds the source code using the S2I PHP builder image, which is available from the OpenShift Container Platform registry as image-registry.openshift-image-registry.svc:5000/openshift/php.

Example usage of the s2i-php task

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: build-and-deploy
spec:
# ...
  tasks:
# ...
  - name: build-s2i
    taskRef:
      resolver: cluster
      params:
      - name: kind
        value: task
      - name: name
        value: s2i-php
      - name: namespace
        value: openshift-pipelines
    workspaces:
    - name: source
      workspace: shared-workspace
# ...

Table 38. Supported parameters for the `s2i-php` task
Parameter	Description	Type	Default value
`IMAGE`	The fully qualified name for the container image that the S2I process builds.	`string`
`IMAGE_SCRIPTS_URL`	The URL containing the default assemble and run scripts for the builder image.	`string`	`image:///usr/libexec/s2i`
`ENV_VARS`	An array of values for environment variables to set in the build process, listed in the `KEY=VALUE` format.	`array`
`CONTEXT`	Path to the directory within the `source` workspace to use as the context.	`string`	`.`
`STORAGE_DRIVER`	Set the Buildah storage driver to reflect the settings of the current cluster node settings.	`string`	`vfs`
`FORMAT`	The format of the container to build, either `oci` or `docker`.	`string`	`oci`
`BUILD_EXTRA_ARGS`	Extra parameters for the `build` command when building the image.	`string`
`PUSH_EXTRA_ARGS`	Extra parameters for the `push` command when pushing the image.	`string`
`SKIP_PUSH`	Skip pushing the image to the container registry.	`string`	`false`
`TLS_VERIFY`	The TLS verification flag, normally `true`.	`string`	`true`
`VERBOSE`	Turn on verbose logging; all commands executed are added to the log.	`string`	`false`
`VERSION`	The tag of the image stream, which corresponds to the language version.	`string`	`latest`

Table 39. Supported workspaces for the `s2i-php` task
Workspace	Description
`source`	The application source code, which is the build context for the S2I workflow.
`dockerconfig`	An optional workspace for providing a `.docker/config.json` file that Buildah uses to access the container registry. Place the file at the root of the workspace with the name `config.json` or `.dockerconfigjson`.

Table 40. Results that the `s2i-php` task returns
Result	Type	Description
`IMAGE_URL`	`string`	The fully qualified name of the image that was built.
`IMAGE_DIGEST`	`string`	Digest of the image that was built.

s2i-python

The s2i-python task builds the source code using the S2I Python builder image, which is available from the OpenShift Container Platform registry as image-registry.openshift-image-registry.svc:5000/openshift/python.

Example usage of the s2i-python task

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: build-and-deploy
spec:
# ...
  tasks:
# ...
  - name: build-s2i
    taskRef:
      resolver: cluster
      params:
      - name: kind
        value: task
      - name: name
        value: s2i-python
      - name: namespace
        value: openshift-pipelines
    workspaces:
    - name: source
      workspace: shared-workspace
# ...

Table 41. Supported parameters for the `s2i-python` task
Parameter	Description	Type	Default value
`IMAGE`	The fully qualified name for the container image that the S2I process builds.	`string`
`IMAGE_SCRIPTS_URL`	The URL containing the default assemble and run scripts for the builder image.	`string`	`image:///usr/libexec/s2i`
`ENV_VARS`	An array of values for environment variables to set in the build process, listed in the `KEY=VALUE` format.	`array`
`CONTEXT`	Path to the directory within the `source` workspace to use as the context.	`string`	`.`
`STORAGE_DRIVER`	Set the Buildah storage driver to reflect the settings of the current cluster node settings.	`string`	`vfs`
`FORMAT`	The format of the container to build, either `oci` or `docker`.	`string`	`oci`
`BUILD_EXTRA_ARGS`	Extra parameters for the `build` command when building the image.	`string`
`PUSH_EXTRA_ARGS`	Extra parameters for the `push` command when pushing the image.	`string`
`SKIP_PUSH`	Skip pushing the image to the container registry.	`string`	`false`
`TLS_VERIFY`	The TLS verification flag, normally `true`.	`string`	`true`
`VERBOSE`	Turn on verbose logging; all commands executed are added to the log.	`string`	`false`
`VERSION`	The tag of the image stream, which corresponds to the language version.	`string`	`latest`

Table 42. Supported workspaces for the `s2i-python` task
Workspace	Description
`source`	The application source code, which is the build context for the S2I workflow.
`dockerconfig`	An optional workspace for providing a `.docker/config.json` file that Buildah uses to access the container registry. Place the file at the root of the workspace with the name `config.json` or `.dockerconfigjson`.

Table 43. Results that the `s2i-python` task returns
Result	Type	Description
`IMAGE_URL`	`string`	The fully qualified name of the image that was built.
`IMAGE_DIGEST`	`string`	Digest of the image that was built.

s2i-ruby

The s2i-ruby task builds the source code using the S2I Ruby builder image, which is available from the OpenShift Container Platform registry as image-registry.openshift-image-registry.svc:5000/openshift/ruby.

Example usage of the s2i-ruby task

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: build-and-deploy
spec:
# ...
  tasks:
# ...
  - name: build-s2i
    taskRef:
      resolver: cluster
      params:
      - name: kind
        value: task
      - name: name
        value: s2i-ruby
      - name: namespace
        value: openshift-pipelines
    workspaces:
    - name: source
      workspace: shared-workspace
# ...

Table 44. Supported parameters for the `s2i-ruby` task
Parameter	Description	Type	Default value
`IMAGE`	The fully qualified name for the container image that the S2I process builds.	`string`
`IMAGE_SCRIPTS_URL`	The URL containing the default assemble and run scripts for the builder image.	`string`	`image:///usr/libexec/s2i`
`ENV_VARS`	An array of values for environment variables to set in the build process, listed in the `KEY=VALUE` format.	`array`
`CONTEXT`	Path to the directory within the `source` workspace to use as the context.	`string`	`.`
`STORAGE_DRIVER`	Set the Buildah storage driver to reflect the settings of the current cluster node settings.	`string`	`vfs`
`FORMAT`	The format of the container to build, either `oci` or `docker`.	`string`	`oci`
`BUILD_EXTRA_ARGS`	Extra parameters for the `build` command when building the image.	`string`
`PUSH_EXTRA_ARGS`	Extra parameters for the `push` command when pushing the image.	`string`
`SKIP_PUSH`	Skip pushing the image to the container registry.	`string`	`false`
`TLS_VERIFY`	The TLS verification flag, normally `true`.	`string`	`true`
`VERBOSE`	Turn on verbose logging; all commands executed are added to the log.	`string`	`false`
`VERSION`	The tag of the image stream, which corresponds to the language version.	`string`	`latest`

Table 45. Supported workspaces for the `s2i-ruby` task
Workspace	Description
`source`	The application source code, which is the build context for the S2I workflow.
`dockerconfig`	An optional workspace for providing a `.docker/config.json` file that Buildah uses to access the container registry. Place the file at the root of the workspace with the name `config.json` or `.dockerconfigjson`.

Table 46. Results that the `s2i-ruby` task returns
Result	Type	Description
`IMAGE_URL`	`string`	The fully qualified name of the image that was built.
`IMAGE_DIGEST`	`string`	Digest of the image that was built.

skopeo-copy

The skopeo-copy task executes the skopeo copy command.

Skopeo is a command-line tool for working with remote container image registries, which does not require a daemon or other infrastructure to load and run the images. The skopeo copy command copies an image from one remote registry to another, for example, from an internal registry to a production registry. Skopeo supports authorization on image registries using credentials that you provide.

Example usage of the skopeo-copy task

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: build-deploy-image
spec:
# ...
  tasks:
  - name: copy-image
    taskRef:
      resolver: cluster
      params:
      - name: kind
        value: task
      - name: name
        value: skopeo-copy
      - name: namespace
        value: openshift-pipelines
    params:
    - name: SOURCE_IMAGE_URL
      value: "docker://internal.registry/myimage:latest"
    - name: DESTINATION_IMAGE_URL
      value: "docker://production.registry/myimage:v1.0"
    workspaces:
    - name: output
      workspace: shared-workspace

Table 47. Supported parameters for the `skopeo-copy` task
Parameter	Description	Type	Default value
`SOURCE_IMAGE_URL`	Fully qualified name, including tag, of the source container image.	`string`
`DESTINATION_IMAGE_URL`	Fully qualified name, including tag, of the destination image to which Skopeo copies the source image.	`string`
`SRC_TLS_VERIFY`	The TLS verification flag for the source registry, normally `true`.	`string`	`true`
`DEST_TLS_VERIFY`	The TLS verification flag for the destination registry, normally `true`	`string`	`true`
`VERBOSE`	Output debug information to the log.	`string`	`false`

Table 48. Supported workspaces for the `skopeo-copy` task
Workspace	Description
`images_url`	If you want to copy more than one image, use this workspace to provide the image URLs.

Table 49. Results that the `skopeo-copy` task returns
Result	Type	Description
`SOURCE_DIGEST`	`string`	The SHA256 digest of the source image.
`DESTINATION_DIGEST`	`string`	The SHA256 digest of the destination image.

Changes from the skopeo-copy ClusterTask

All parameter names were changed to uppercase.
The VERBOSE parameter was added.
The workspace name was changed from images-url to images_url.
The SOURCE_DIGEST and DESTINATION_DIGEST results were added.

tkn

The tkn task performs operations on Tekton resources using tkn.

Example usage of the tkn task

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
 name: tkn-run
spec:
 pipelineSpec:
   tasks:
   - name: tkn-run
     taskRef:
       resolver: cluster
       params:
       - name: kind
         value: task
       - name: name
         value: tkn
       - name: namespace
         value: openshift-pipelines
     params:
     - name: ARGS

Table 50. Supported parameters for the `tkn` task
Parameter	Description	Type	Default value
`SCRIPT`	The `tkn` CLI script to execute.	`string`	`tkn $@`
`ARGS`	The `tkn` CLI arguments to run.	`array`	`- --help`

Table 51. Supported workspaces for the `tkn` task
Workspace	Description
`kubeconfig_dir`	An optional workspace in which you can provide a `.kube/config` file that contains credentials for accessing the cluster. Place this file at the root of the workspace and name it `kubeconfig`.

Changes from the tkn ClusterTask

The TKN_IMAGE parameter was removed.
The workspace name was changed from kubeconfig to kubeconfig_dir.

Step action provided with OpenShift Pipelines

OpenShift Pipelines provides a standard StepAction definition that you can use in your tasks. Use the cluster resolver to reference this definition.

git-clone

The git-clone step action uses Git to initialize and clone a remote repository on a workspace. You can use this step action to define a task that clones a repository at the start of a pipeline that builds or otherwise processes this source code.

Example usage of the git-clone step action in a task

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: clone-repo-anon
spec:
# ...
  steps:
  - name: clone-repo-step
    ref:
      resolver: cluster
      params:
      - name: name
        value: git-clone
      - name: namespace
        value: openshift-pipelines
      - name: kind
        value: stepaction
    params:
    - name: URL
      value: $(params.url)
    - name: OUTPUT_PATH
      value: $(workspaces.output.path)

Table 52. Supported parameters for the `git-clone` step action
Parameter	Description	Type	Default value
`OUTPUT_PATH`	A directory for the fetched Git repository. Cloned repo data is placed in the root of the directory or in the relative path defined by the `SUBDIRECTORY` parameter	`string`
`SSH_DIRECTORY_PATH`	A `.ssh` directory with the private key, `known_hosts`, `config`, and other files as necessary. If you provide this directory, the task uses it for authentication to the Git repository. Bind the workspace providing this directory to a `Secret` resource for secure storage of authentication information.	`string`
`BASIC_AUTH_PATH`	A directory containing a `.gitconfig` and `.git-credentials` files. If you provide this directgory, the task uses it for authentication to the Git repository. Use a `SSH_DIRECTORY_PATH` directory for authentication instead of `BASIC_AUTH_PATH` whenever possible. Bind the workspace providing this directory to a `Secret` resource for secure storage of authentication information.	`string`
`SSL_CA_DIRECTORY_PATH`	A workspace containing CA certificates. If you provide this workspace, Git uses these certificates to verify the peer when interacting with remote repositories using HTTPS.	`string`
`CRT_FILENAME`	Certificate authority (CA) bundle filename in the `ssl-ca-directory` workspace.	`string`	`ca-bundle.crt`
`HTTP_PROXY`	HTTP proxy server (non-TLS requests).	`string`
`HTTPS_PROXY`	HTTPS proxy server (TLS requests).	`string`
`NO_PROXY`	Opt out of proxying HTTP/HTTPS requests.	`string`
`SUBDIRECTORY`	Relative path in the `output` workspace where the task places the Git repository.	`string`
`USER_HOME`	Absolute path to the Git user home directory in the pod.	`string`	`/home/git`
`DELETE_EXISTING`	Delete the contents of the default workspace, if they exist, before running the Git operations.	`string`	`true`
`VERBOSE`	Log the executed commands.	`string`	`false`
`SSL_VERIFY`	The global `http.sslVerify` value. Do not set this parameter to to `false` unless you trust the remote repository.	`string`	`true`
`URL`	Git repository URL.	`string`
`REVISION`	The revision to check out, for example, a branch or tag.	`string`	`main`
`REFSPEC`	The `refspec` string for the repository that the task fetches before checking out the revision.	`string`
`SUBMODULES`	Initialize and fetch Git submodules.	`string`	`true`
`DEPTH`	Number of commits to fetch, a "shallow clone" is a single commit.	`string`	`1`
`SPARSE_CHECKOUT_DIRECTORIES`	List of directory patterns, separated by commas, for performing a "sparse checkout".	`string`

Table 53. Results that the `git-clone` step action returns
Result	Type	Description
`COMMIT`	`string`	The SHA digest of the commit that is at the HEAD of the current branch in the cloned Git repository.
`URL`	`string`	The URL of the repository that was cloned.
`COMMITTER_DATE`	`string`	The epoch timestamp of the commit that is at the HEAD of the current branch in the cloned Git repository.

About non-versioned and versioned tasks and step actions

The openshift-pipelines namespace includes versioned tasks and step actions alongside standard non-versioned tasks and step actions. For example, installing the Red Hat OpenShift Pipelines Operator v1.16 creates the following items:

buildah-1-16-0 versioned task
buildah non-versioned task
git-clone-1-16-0 versioned StepAction definition
git-clone non-versioned StepAction definition

Non-versioned and versioned tasks and step actions have the same metadata, behavior, and specifications, including params, workspaces, and steps. However, they behave differently when you disable them or upgrade the Operator.

Before adopting non-versioned or versioned tasks and step actions as a standard in production environments, cluster administrators might consider their advantages and disadvantages.

Table 54. Advantages and disadvantages of non-versioned and versioned tasks and step actions
	Advantages	Disadvantages
Non-versioned tasks and step actions	If you prefer deploying pipelines with the latest updates and bug fixes, use non-versioned tasks and step actions. Upgrading the Operator upgrades the non-versioned tasks and step actions, which consumes fewer resources than multiple versioned tasks and step actions.	If you deploy pipelines that use non-versioned tasks and step actions, they might break after an Operator upgrade if the automatically upgraded tasks and step actions are not backward-compatible.
Versioned tasks and step actions	If you prefer stable pipelines in production, use versioned tasks and step actions. Earlier versions are retained on the cluster even after the later version of a task or step action is installed. You can continue using the earlier versions.	If you continue using the earlier versions, you might miss the latest features and critical security updates. The earlier versions that are not operational consume cluster resources. After an upgrade, the Operator cannot manage the earlier versioned tasks and step actions. You can delete the earlier versions manually, but you cannot restore them.

Non-versioned and versioned tasks and step actions have different naming conventions, and the Red Hat OpenShift Pipelines Operator upgrades them differently.

Table 55. Differences between non-versioned and versioned tasks and step actions
	Nomenclature	Upgrade
Non-versioned tasks and step actions	Non-versioned tasks and step actions only contain the name of the task or step action. For example, the name of the non-versioned task of Buildah installed with Operator v1.16 is `buildah`.	When you upgrade the Operator, it updates the non-versioned tasks and step actions with the latest changes. The name remains unchanged.
Versioned tasks and step actions	Versioned tasks and step actions contain the name, followed by the version as a suffix. For example, the name of the versioned task of Buildah installed with Operator v1.16 is `buildah-1-16-0`.	Upgrading the Operator installs the latest version of versioned tasks and step actions and retains the earlier version. The latest version corresponds to the upgraded Operator. For example, installing Operator 1.17 installs the `git-clone-1-17-0` step action and retains the `git-clone-1-16-0` step action.

Additional resources

Using Tekton Hub with OpenShift Pipelines

Specifying remote pipelines, tasks, and step actions using resolvers

Specifying a remote pipeline, task, or step action from a Tekton catalog

Configuring the hub resolver

Specifying a remote pipeline, task, or step action using the hub resolver

Specifying a remote pipeline, task, or step action from a Tekton bundle

Configuring the bundles resolver

Specifying a remote pipeline, task, or step action using the bundles resolver

Specifying a remote pipeline, task, or step action with anonymous Git cloning

Configuring the Git resolver for anonymous Git cloning

Specifying a remote pipeline, task, or step action by using the Git resolver for anonymous cloning

Specifying a remote pipeline, task, or step action with an authenticated Git API

Configuring the Git resolver for an authenticated API

Configuring multiple Git providers

Specifying a remote pipeline, task, or step action using the Git resolver with the authenticated SCM API

Specifying multiple Git providers

Specifying a remote pipeline or task by using the Git resolver with the authenticated SCM API overriding the Git resolver configuration

Specifying a remote pipeline, task, or step action by using the HTTP resolver

Configuring the HTTP resolver

Specifying a remote pipeline, task, or step action with the HTTP Resolver

Specifying a pipeline, task, or step action from the same cluster

Configuring the cluster resolver

Specifying a pipeline, task, or step action from the same cluster using the cluster resolver

Tasks provided in the OpenShift Pipelines namespace

buildah

git-cli

git-clone

kn

kn-apply

maven

openshift-client

s2i-dotnet

s2i-go

s2i-java

s2i-nodejs

s2i-perl

s2i-php

s2i-python

s2i-ruby

skopeo-copy

tkn

Step action provided with OpenShift Pipelines

git-clone

About non-versioned and versioned tasks and step actions

Additional resources