SupportConsoleDéveloppeursCommencer un essaiContact

Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 3. Specifying remote pipelines and tasks using resolvers

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.

In these cases, the resolvers in Red Hat OpenShift Pipelines retrieve the pipeline or task 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 or pipeline from the Pipelines Catalog available on Artifact Hub or Tekton Hub.
Bundles resolver
Retrieves a task or pipeline from a Tekton bundle, which is an OCI image available from any OCI repository, such as an OpenShift container repository.
Cluster resolver
Retrieves a task or pipeline that is already created on the same OpenShift Container Platform cluster in a specific namespace.
Git resolver
Retrieves a task or pipeline binding from a Git repository. You must specify the repository, the branch, and the path.

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.

3.1. Specifying a remote pipeline or task from a Tekton catalog

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

Important

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

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

  1. To edit the TektonConfig custom resource, enter the following command: 

    $ oc edit TektonConfig config

  2. 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.
    Important

    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.

3.1.2. Specifying a remote pipeline or task 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.

Procedure

  • To specify a remote pipeline or task from Artifact Hub or Tekton Hub, use the following reference format in the pipelineRef or taskRef 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 3.1. Supported parameters for the hub resolver
    ParameterDescriptionExample 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.

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 that references a remote task from a catalog: 

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: pipeline-with-cluster-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 that references a remote task from a catalog: 

apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  name: cluster-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

3.2. Specifying a remote pipeline or task from a Tekton bundle

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

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

  1. To edit the TektonConfig custom resource, enter the following command: 

    $ oc edit TektonConfig config

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

3.2.2. Specifying a remote pipeline or task 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.

Procedure

  • To specify a remote pipeline or task from a Tekton bundle, use the following reference format in the pipelineRef or taskRef spec: 

    # ...
  resolver: bundles
  params:
  - name: bundle
    value: <fully_qualified_image_name>
  - name: name
    value: <resource_name>
  - name: kind
    value: [pipeline|task]
# ...
    Table 3.2. Supported parameters for the bundles resolver
    ParameterDescriptionExample 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

    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.

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

3.3. Specifying a remote pipeline or task from a Git repository

You can use the Git resolver to specify a remote pipeline or task from a Git repostory. The repository must contain a YAML file that defines the pipeline or task. The Git resolver can access a repository either by cloning it anonymously or by using the authenticated SCM API.

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

  1. To edit the TektonConfig custom resource, enter the following command: 

    $ oc edit TektonConfig config

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

3.3.2. Configuring the Git resolver for the authenticated SCM API

For the authenticated 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
Note
  • You can configure only one Git connection using the authenticated SCM API for your cluster. This connection becomes available to all users of the cluster. All users of the cluster can access the repository using the security token that you configure for the connection.
  • 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

  1. To edit the TektonConfig custom resource, enter the following command: 

    $ oc edit TektonConfig config

  2. 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.
Note

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

3.3.3. Specifying a remote pipeline or task using the Git resolver

When creating a pipeline run, you can specify a remote pipeline from a Git repository. When creating a pipeline or a task run, you can specify a remote task 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

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

    # ...
  resolver: git
  params:
  - name: url
    value: <git_repository_url>
  - name: revision
    value: <branch_name>
  - name: pathInRepo
    value: <path_in_repository>
# ...
    Table 3.3. Supported parameters for the Git resolver
    ParameterDescriptionExample value

    url

    The URL of the repository, when using anonymous cloning.

    https://github.com/tektoncd/catalog.git

    repo

    The repository name, when using the authenticated SCM API.

    test-infra

    org

    The organization for the repository, when using the authenticated SCM API.

    tektoncd

    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

    Note

    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.

    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.

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: 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/v1
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

3.4. Specifying a remote pipeline or task from the same cluster

You can use the cluster resolver to specify a remote pipeline or task 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.

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

  1. To edit the TektonConfig custom resource, enter the following command: 

    $ oc edit TektonConfig config

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

3.4.2. Specifying a remote pipeline or task using the cluster resolver

When creating a pipeline run, you can specify a remote pipeline from the same cluster. When creating a pipeline or a task run, you can specify a remote task from the same cluster.

Procedure

  • To specify a remote pipeline or task from the same cluster, use the following reference format in the pipelineRef or taskRef spec: 

    # ...
  resolver: cluster
  params:
  - name: name
    value: <name>
  - name: namespace
    value: <namespace>
  - name: kind
    value: [pipeline|task]
# ...
    Table 3.4. Supported parameters for the cluster resolver
    ParameterDescriptionExample 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.

The following example pipeline run references a remote 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 remote 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 remote 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

3.5. Tasks provided in the OpenShift Pipelines 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.

ClusterTask functionality is deprecated since OpenShift Pipelines 1.10 and is planned for removal in a future release. If your pipelines use ClusterTasks, 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 existing ClusterTasks.

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 3.5. Supported parameters for the buildah task
ParameterDescriptionTypeDefault 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 3.6. Supported workspaces for the buildah task
WorkspaceDescription

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 3.7. Results that the buildah task returns
ResultTypeDescription

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 3.8. Supported parameters for the git-cli task
ParameterDescriptionTypeDefault 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 3.9. Supported workspaces for the git-cli task
WorkspaceDescription

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 3.10. Results that the git-cli task returns
ResultTypeDescription

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 3.11. Supported parameters for the git-clone task
ParameterDescriptionTypeDefault 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 3.12. Supported workspaces for the git-clone task
WorkspaceDescription

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 3.13. Results that the git-clone task returns
ResultTypeDescription

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 3.14. Supported parameters for the kn task
ParameterDescriptionTypeDefault 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 3.15. Supported parameters for the kn-apply task
ParameterDescriptionTypeDefault 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 3.16. Supported parameters for the maven task
ParameterDescriptionTypeDefault 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 3.17. Supported workspaces for the maven task
WorkspaceDescription

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 3.18. Supported parameters for the openshift-client task
ParameterDescriptionTypeDefault value

SCRIPT

The oc CLI arguments to run.

string

oc help

VERSION

The OpenShift Container Platform version to use.

string

latest

Table 3.19. Supported workspaces for the openshift-client task
WorkspaceDescription

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 3.20. Supported parameters for the s2i-dotnet task
ParameterDescriptionTypeDefault 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 3.21. Supported workspaces for the s2i-dotnet task
WorkspaceDescription

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 3.22. Results that the s2i-dotnet task returns
ResultTypeDescription

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-dotnet ClusterTask

  • Several new parameters were added.
  • The BASE_IMAGE parameter was removed.
  • 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-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 3.23. Supported parameters for the s2i-go task
ParameterDescriptionTypeDefault 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 3.24. Supported workspaces for the s2i-go task
WorkspaceDescription

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 3.25. Results that the s2i-go task returns
ResultTypeDescription

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-go ClusterTask

  • Several new parameters were added.
  • The BASE_IMAGE parameter was removed.
  • 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-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 3.26. Supported parameters for the s2i-java task
ParameterDescriptionTypeDefault 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 3.27. Supported workspaces for the s2i-java task
WorkspaceDescription

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 3.28. Results that the s2i-java task returns
ResultTypeDescription

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 3.29. Supported parameters for the s2i-nodejs task
ParameterDescriptionTypeDefault 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 3.30. Supported workspaces for the s2i-nodejs task
WorkspaceDescription

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 3.31. Results that the s2i-nodejs task returns
ResultTypeDescription

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-nodejs ClusterTask

  • Several new parameters were added.
  • The BASE_IMAGE parameter was removed.
  • 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-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 3.32. Supported parameters for the s2i-perl task
ParameterDescriptionTypeDefault 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 3.33. Supported workspaces for the s2i-perl task
WorkspaceDescription

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 3.34. Results that the s2i-perl task returns
ResultTypeDescription

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-perl ClusterTask

  • Several new parameters were added.
  • The BASE_IMAGE parameter was removed.
  • 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-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 3.35. Supported parameters for the s2i-php task
ParameterDescriptionTypeDefault 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 3.36. Supported workspaces for the s2i-php task
WorkspaceDescription

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 3.37. Results that the s2i-php task returns
ResultTypeDescription

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-php ClusterTask

  • Several new parameters were added.
  • The BASE_IMAGE parameter was removed.
  • 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-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 3.38. Supported parameters for the s2i-python task
ParameterDescriptionTypeDefault 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 3.39. Supported workspaces for the s2i-python task
WorkspaceDescription

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 3.40. Results that the s2i-python task returns
ResultTypeDescription

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-python ClusterTask

  • Several new parameters were added.
  • The BASE_IMAGE parameter was removed.
  • 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-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 3.41. Supported parameters for the s2i-ruby task
ParameterDescriptionTypeDefault 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 3.42. Supported workspaces for the s2i-ruby task
WorkspaceDescription

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 3.43. Results that the s2i-ruby task returns
ResultTypeDescription

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-ruby ClusterTask

  • Several new parameters were added.
  • The BASE_IMAGE parameter was removed.
  • The parameter name PATH_CONTEXT was changed to CONTEXT.
  • The parameter name TLS_VERIFY was changed to TLSVERIFY.
  • The IMAGE_URL result was added.

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 3.44. Supported parameters for the skopeo-copy task
ParameterDescriptionTypeDefault 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 3.45. Supported workspaces for the skopeo-copy task
WorkspaceDescription

images_url

If you want to copy more than one image, use this workspace to provide the image URLs.

Table 3.46. Results that the skopeo-copy task returns
ResultTypeDescription

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 3.47. Supported parameters for the tkn task
ParameterDescriptionTypeDefault value

SCRIPT

The tkn CLI script to execute.

string

tkn $@

ARGS

The tkn CLI arguments to run.

array

- --help

Table 3.48. Supported workspaces for the tkn task
WorkspaceDescription

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.

3.6. Additional resources

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.