Questo contenuto non è disponibile nella lingua selezionata.
Chapter 3. Specifying remote pipelines, tasks, and step actions 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.
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.
3.1. 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.
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
To edit the
TektonConfig
custom resource, enter the following command:$ oc edit TektonConfig config
In the
TektonConfig
custom resource, edit thepipeline.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 ortekton
for Tekton Hub. - 6
- The Tekton Hub API used, if the
default-type
option is set totekton
. - 7
- Optional: The Artifact Hub API used, if the
default-type
option is set toartifact
.
ImportantIf you set the
default-type
option totekton
, you must configure your own instance of the Tekton Hub by setting thetekton-hub-api
value.If you set the
default-type
option toartifact
then the resolver uses the public hub API at https://artifacthub.io/ by default. You can configure your own Artifact Hub API by setting theartifact-hub-api
value.
3.1.2. 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 thepipelineRef
,taskRef
, orstep.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 3.1. Supported parameters for the hub resolver Parameter Description Example value catalog
The catalog for pulling the resource.
Default:
tekton-catalog-tasks
(for thetask
kind);tekton-catalog-pipelines
(for thepipeline
kind).type
The type of the catalog for pulling the resource. Either
artifact
for Artifact Hub ortekton
for Tekton Hub.Default:
artifact
kind
Either
task
orpipeline
.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. Theparams
section of thepipelineRef
ortaskRef
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
3.2. 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.
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
To edit the
TektonConfig
custom resource, enter the following command:$ oc edit TektonConfig config
In the
TektonConfig
custom resource, edit thepipeline.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
3.2.2. 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 thepipelineRef
,taskRef
, orstep.ref
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 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
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. Theparams
section of thepipelineRef
ortaskRef
specification must contain only the parameters that the resolver supports.
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
3.3. 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.
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
To edit the
TektonConfig
custom resource, enter the following command:$ oc edit TektonConfig config
In the
TektonConfig
custom resource, edit thepipeline.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. 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 thepipelineRef
,taskRef
, orstep.ref
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 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
NoteTo clone and fetch the repository anonymously, use the
url
parameter. Do not specify theurl
parameter and therepo
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
3.4. 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.
3.4.1. 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 thepipeline.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.
3.4.2. 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 thepipeline.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" # ...
WarningconfigKey
values with the.
symbol are not supported. If you try to pass aconfigKey
value that contains the.
symbol, theTaskRun
orPipelineRun
resource where you passed the value fails to run.
3.4.3. 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 thepipelineRef
,taskRef
, orstep.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 3.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
NoteTo clone and fetch the repository anonymously, use the
url
parameter. To use the authenticated SCM API, use therepo
parameter. Do not specify theurl
parameter and therepo
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. Theparams
section of thepipelineRef
ortaskRef
specification must contain only the parameters that the resolver supports.
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
3.4.4. 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
.
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.
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
andtaskRef
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
.
3.4.5. 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
Parameter | Description | Example value |
---|---|---|
| The organization for the repository. |
|
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. |
|
3.5. 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.
3.5.1. 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 thepipeline.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.
3.5.2. 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 thepipelineRef
,taskRef
, orstep.ref
spec:# ... resolver: http params: - name: url value: <fully_qualified_http_url> # ...
Table 3.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
3.6. 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.
3.6.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
To edit the
TektonConfig
custom resource, enter the following command:$ oc edit TektonConfig config
In the
TektonConfig
custom resource, edit thepipeline.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.6.2. 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 thepipelineRef
,taskRef
, orstep.ref
spec:# ... resolver: cluster params: - name: name value: <name> - name: namespace value: <namespace> - name: kind value: [pipeline|task|stepaction] # ...
Table 3.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
3.7. 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.
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 # ...
Parameter | Description | Type | Default value |
---|---|---|---|
| Fully qualified container image name to be built by Buildah. |
| |
|
Path to the |
|
|
| Path to the directory to use as the context. |
|
|
| Set the Buildah storage driver to reflect the settings of the current cluster node settings. |
|
|
|
The format of the container to build, either |
|
|
|
Extra parameters for the |
| |
|
Extra parameters for the |
| |
| Skip pushing the image to the container registry. |
|
|
|
The TLS verification flag, normally |
|
|
| Turn on verbose logging; all commands executed are added to the log. |
|
|
Workspace | Description |
---|---|
|
Container build context, usually the application source code that includes a |
|
An optional workspace for providing a |
|
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 |
Result | Type | Description |
---|---|---|
|
| The fully qualified name of the image that was built. |
|
| 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.
Parameter | Description | Type | Default value |
---|---|---|---|
|
Certificate Authority (CA) bundle filename in the |
|
|
| HTTP proxy server (non-TLS requests). |
| |
| HTTPS proxy server (TLS requests). |
| |
| Opt out of proxying HTTP/HTTPS requests. |
| |
|
Relative path to the |
| |
| Absolute path to the Git user home directory in the pod. |
|
|
|
Erase any existing contents of the |
|
|
| Log all the executed commands. |
|
|
|
The global |
|
|
| Git user name for performing Git operations. |
| |
| Git user email for performing Git operations. |
| |
| The Git script to run. |
|
|
Workspace | Description |
---|---|
|
A |
|
A workspace containing a |
| 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. |
| A workspace that contains the fetched Git repository. |
|
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
|
Result | Type | Description |
---|---|---|
|
| 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
andVERBOSE
parameters were changed. -
The name of the result was changed from
commit
toCOMMIT
.
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
Parameter | Description | Type | Default value |
---|---|---|---|
|
Certificate Authority (CA) bundle filename in the |
|
|
| HTTP proxy server (non-TLS requests). |
| |
| HTTPS proxy server (TLS requests). |
| |
| Opt out of proxying HTTP/HTTPS requests. |
| |
|
Relative path in the |
| |
| Absolute path to the Git user home directory in the pod. |
|
|
| Delete the contents of the default workspace, if they exist, before running the Git operations. |
|
|
| Log the executed commands. |
|
|
|
The global |
|
|
| Git repository URL. |
| |
| The revision to check out, for example, a branch or tag. |
|
|
|
The |
| |
| Initialize and fetch Git submodules. |
|
|
| Number of commits to fetch, a "shallow clone" is a single commit. |
|
|
| List of directory patterns, separated by commas, for performing a "sparse checkout". |
|
Workspace | Description |
---|---|
|
A |
|
A workspace containing a |
| 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. |
|
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 |
Result | Type | Description |
---|---|---|
|
| The SHA digest of the commit that is at the HEAD of the current branch in the cloned Git repository. |
|
| The URL of the repository that was cloned. |
|
| 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]
Parameter | Description | Type | Default value |
---|---|---|---|
|
The arguments for the |
|
|
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"
Parameter | Description | Type | Default value |
---|---|---|---|
| The Knative service name. |
| |
| The fully qualified name of the image to deploy. |
|
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 # ...
Parameter | Description | Type | Default value |
---|---|---|---|
| The Maven goals to run. |
|
|
| The Maven repository mirror URL. |
| |
|
The subdirectory within the |
|
|
Workspace | Description |
---|---|
| The workspace that contains the Maven project. |
| The workspace that contains the secrets for connecting to the Maven server, such as the user name and password. |
| The workspace that contains the credentials for connecting to the proxy server, such as the user name and password. |
|
The workspace that contains proxy configuration values, such as |
| The workspace that contains custom Maven settings. |
Changes from the maven
ClusterTask
-
The parameter name
CONTEXT_DIR
was changed toSUBDIRECTORY
. -
The workspace name
maven-settings
was changed tomaven_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"
Parameter | Description | Type | Default value |
---|---|---|---|
|
The |
|
|
| The OpenShift Container Platform version to use. |
|
|
Workspace | Description |
---|---|
|
The workspace containing manifest files that you want to apply using the |
|
An optional workspace in which you can provide a |
Changes from the openshift-client
ClusterTask
-
The workspace name
manifest-dir
was changed tomanifest_dir
. -
The workspace name
kubeconfig-dir
was changed tokubeconfig_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 # ...
Parameter | Description | Type | Default value |
---|---|---|---|
| The fully qualified name for the container image that the S2I process builds. |
| |
| The URL containing the default assemble and run scripts for the builder image. |
|
|
|
An array of values for environment variables to set in the build process, listed in the |
| |
|
Path to the directory within the |
|
|
| Set the Buildah storage driver to reflect the settings of the current cluster node settings. |
|
|
|
The format of the container to build, either |
|
|
|
Extra parameters for the |
| |
|
Extra parameters for the |
| |
| Skip pushing the image to the container registry. |
|
|
|
The TLS verification flag, normally |
|
|
| Turn on verbose logging; all commands executed are added to the log. |
|
|
| The tag of the image stream, which corresponds to the language version. |
|
|
Workspace | Description |
---|---|
| The application source code, which is the build context for the S2I workflow. |
|
An optional workspace for providing a |
Result | Type | Description |
---|---|---|
|
| The fully qualified name of the image that was built. |
|
| 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 # ...
Parameter | Description | Type | Default value |
---|---|---|---|
| The fully qualified name for the container image that the S2I process builds. |
| |
| The URL containing the default assemble and run scripts for the builder image. |
|
|
|
An array of values for environment variables to set in the build process, listed in the |
| |
|
Path to the directory within the |
|
|
| Set the Buildah storage driver to reflect the settings of the current cluster node settings. |
|
|
|
The format of the container to build, either |
|
|
|
Extra parameters for the |
| |
|
Extra parameters for the |
| |
| Skip pushing the image to the container registry. |
|
|
|
The TLS verification flag, normally |
|
|
| Turn on verbose logging; all commands executed are added to the log. |
|
|
| The tag of the image stream, which corresponds to the language version. |
|
|
Workspace | Description |
---|---|
| The application source code, which is the build context for the S2I workflow. |
|
An optional workspace for providing a |
Result | Type | Description |
---|---|---|
|
| The fully qualified name of the image that was built. |
|
| 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
.
Parameter | Description | Type | Default value |
---|---|---|---|
| The fully qualified name for the container image that the S2I process builds. |
| |
| The URL containing the default assemble and run scripts for the builder image. |
|
|
|
An array of values for environment variables to set in the build process, listed in the |
| |
|
Path to the directory within the |
|
|
| Set the Buildah storage driver to reflect the settings of the current cluster node settings. |
|
|
|
The format of the container to build, either |
|
|
|
Extra parameters for the |
| |
|
Extra parameters for the |
| |
| Skip pushing the image to the container registry. |
|
|
|
The TLS verification flag, normally |
|
|
| Turn on verbose logging; all commands executed are added to the log. |
|
|
| The tag of the image stream, which corresponds to the language version. |
|
|
Workspace | Description |
---|---|
| The application source code, which is the build context for the S2I workflow. |
|
An optional workspace for providing a |
Result | Type | Description |
---|---|---|
|
| The fully qualified name of the image that was built. |
|
| 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
, andMAVEN_MIRROR_URL
parameters were removed. You can pass theMAVEN_ARGS_APPEND
,MAVEN_CLEAR_REPO
, andMAVEN_MIRROR_URL
values as environment variables. -
The parameter name
PATH_CONTEXT
was changed toCONTEXT
. -
The parameter name
TLS_VERIFY
was changed toTLSVERIFY
. -
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 # ...
Parameter | Description | Type | Default value |
---|---|---|---|
| The fully qualified name for the container image that the S2I process builds. |
| |
| The URL containing the default assemble and run scripts for the builder image. |
|
|
|
An array of values for environment variables to set in the build process, listed in the |
| |
|
Path to the directory within the |
|
|
| Set the Buildah storage driver to reflect the settings of the current cluster node settings. |
|
|
|
The format of the container to build, either |
|
|
|
Extra parameters for the |
| |
|
Extra parameters for the |
| |
| Skip pushing the image to the container registry. |
|
|
|
The TLS verification flag, normally |
|
|
| Turn on verbose logging; all commands executed are added to the log. |
|
|
| The tag of the image stream, which corresponds to the language version. |
|
|
Workspace | Description |
---|---|
| The application source code, which is the build context for the S2I workflow. |
|
An optional workspace for providing a |
Result | Type | Description |
---|---|---|
|
| The fully qualified name of the image that was built. |
|
| 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 # ...
Parameter | Description | Type | Default value |
---|---|---|---|
| The fully qualified name for the container image that the S2I process builds. |
| |
| The URL containing the default assemble and run scripts for the builder image. |
|
|
|
An array of values for environment variables to set in the build process, listed in the |
| |
|
Path to the directory within the |
|
|
| Set the Buildah storage driver to reflect the settings of the current cluster node settings. |
|
|
|
The format of the container to build, either |
|
|
|
Extra parameters for the |
| |
|
Extra parameters for the |
| |
| Skip pushing the image to the container registry. |
|
|
|
The TLS verification flag, normally |
|
|
| Turn on verbose logging; all commands executed are added to the log. |
|
|
| The tag of the image stream, which corresponds to the language version. |
|
|
Workspace | Description |
---|---|
| The application source code, which is the build context for the S2I workflow. |
|
An optional workspace for providing a |
Result | Type | Description |
---|---|---|
|
| The fully qualified name of the image that was built. |
|
| 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 # ...
Parameter | Description | Type | Default value |
---|---|---|---|
| The fully qualified name for the container image that the S2I process builds. |
| |
| The URL containing the default assemble and run scripts for the builder image. |
|
|
|
An array of values for environment variables to set in the build process, listed in the |
| |
|
Path to the directory within the |
|
|
| Set the Buildah storage driver to reflect the settings of the current cluster node settings. |
|
|
|
The format of the container to build, either |
|
|
|
Extra parameters for the |
| |
|
Extra parameters for the |
| |
| Skip pushing the image to the container registry. |
|
|
|
The TLS verification flag, normally |
|
|
| Turn on verbose logging; all commands executed are added to the log. |
|
|
| The tag of the image stream, which corresponds to the language version. |
|
|
Workspace | Description |
---|---|
| The application source code, which is the build context for the S2I workflow. |
|
An optional workspace for providing a |
Result | Type | Description |
---|---|---|
|
| The fully qualified name of the image that was built. |
|
| 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 # ...
Parameter | Description | Type | Default value |
---|---|---|---|
| The fully qualified name for the container image that the S2I process builds. |
| |
| The URL containing the default assemble and run scripts for the builder image. |
|
|
|
An array of values for environment variables to set in the build process, listed in the |
| |
|
Path to the directory within the |
|
|
| Set the Buildah storage driver to reflect the settings of the current cluster node settings. |
|
|
|
The format of the container to build, either |
|
|
|
Extra parameters for the |
| |
|
Extra parameters for the |
| |
| Skip pushing the image to the container registry. |
|
|
|
The TLS verification flag, normally |
|
|
| Turn on verbose logging; all commands executed are added to the log. |
|
|
| The tag of the image stream, which corresponds to the language version. |
|
|
Workspace | Description |
---|---|
| The application source code, which is the build context for the S2I workflow. |
|
An optional workspace for providing a |
Result | Type | Description |
---|---|---|
|
| The fully qualified name of the image that was built. |
|
| 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 # ...
Parameter | Description | Type | Default value |
---|---|---|---|
| The fully qualified name for the container image that the S2I process builds. |
| |
| The URL containing the default assemble and run scripts for the builder image. |
|
|
|
An array of values for environment variables to set in the build process, listed in the |
| |
|
Path to the directory within the |
|
|
| Set the Buildah storage driver to reflect the settings of the current cluster node settings. |
|
|
|
The format of the container to build, either |
|
|
|
Extra parameters for the |
| |
|
Extra parameters for the |
| |
| Skip pushing the image to the container registry. |
|
|
|
The TLS verification flag, normally |
|
|
| Turn on verbose logging; all commands executed are added to the log. |
|
|
| The tag of the image stream, which corresponds to the language version. |
|
|
Workspace | Description |
---|---|
| The application source code, which is the build context for the S2I workflow. |
|
An optional workspace for providing a |
Result | Type | Description |
---|---|---|
|
| The fully qualified name of the image that was built. |
|
| 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
Parameter | Description | Type | Default value |
---|---|---|---|
| Fully qualified name, including tag, of the source container image. |
| |
| Fully qualified name, including tag, of the destination image to which Skopeo copies the source image. |
| |
|
The TLS verification flag for the source registry, normally |
|
|
|
The TLS verification flag for the destination registry, normally |
|
|
| Output debug information to the log. |
|
|
Workspace | Description |
---|---|
| If you want to copy more than one image, use this workspace to provide the image URLs. |
Result | Type | Description |
---|---|---|
|
| The SHA256 digest of the source image. |
|
| 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
toimages_url
. -
The
SOURCE_DIGEST
andDESTINATION_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
Parameter | Description | Type | Default value |
---|---|---|---|
|
The |
|
|
|
The |
|
|
Workspace | Description |
---|---|
|
An optional workspace in which you can provide a |
Changes from the tkn
ClusterTask
-
The
TKN_IMAGE
parameter was removed. -
The workspace name was changed from
kubeconfig
tokubeconfig_dir
.
3.8. 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)
Parameter | Description | Type | Default value |
---|---|---|---|
|
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 |
| |
|
A |
| |
|
A directory containing a |
| |
| 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. |
| |
|
Certificate authority (CA) bundle filename in the |
|
|
| HTTP proxy server (non-TLS requests). |
| |
| HTTPS proxy server (TLS requests). |
| |
| Opt out of proxying HTTP/HTTPS requests. |
| |
|
Relative path in the |
| |
| Absolute path to the Git user home directory in the pod. |
|
|
| Delete the contents of the default workspace, if they exist, before running the Git operations. |
|
|
| Log the executed commands. |
|
|
|
The global |
|
|
| Git repository URL. |
| |
| The revision to check out, for example, a branch or tag. |
|
|
|
The |
| |
| Initialize and fetch Git submodules. |
|
|
| Number of commits to fetch, a "shallow clone" is a single commit. |
|
|
| List of directory patterns, separated by commas, for performing a "sparse checkout". |
|
Result | Type | Description |
---|---|---|
|
| The SHA digest of the commit that is at the HEAD of the current branch in the cloned Git repository. |
|
| The URL of the repository that was cloned. |
|
| The epoch timestamp of the commit that is at the HEAD of the current branch in the cloned Git repository. |
3.9. 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
versionedStepAction
definition -
git-clone
non-versionedStepAction
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.
Advantages | Disadvantages | |
---|---|---|
Non-versioned tasks and step actions |
|
|
Versioned tasks and step actions |
|
|
Non-versioned and versioned tasks and step actions have different naming conventions, and the Red Hat OpenShift Pipelines Operator upgrades them differently.
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 | 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 |
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 |