Chapter 2. Understanding OpenShift Pipelines Red Hat OpenShift Pipelines is a cloud-native, continuous integration and continuous delivery (CI/CD) solution based on Kubernetes resources. It uses Tekton building blocks to automate deployments across multiple platforms by abstracting away the underlying implementation details. Tekton introduces a number of standard custom resource definitions (CRDs) for defining CI/CD pipelines that are portable across Kubernetes distributions. 2.1. Key features Red Hat OpenShift Pipelines is a serverless CI/CD system that runs pipelines with all the required dependencies in isolated containers. Red Hat OpenShift Pipelines are designed for decentralized teams that work on microservice-based architecture. Red Hat OpenShift Pipelines use standard CI/CD pipeline definitions that are easy to extend and integrate with the existing Kubernetes tools, enabling you to scale on-demand. You can use Red Hat OpenShift Pipelines to build images with Kubernetes tools such as Source-to-Image (S2I), Buildah, Buildpacks, and Kaniko that are portable across any Kubernetes platform. You can use the OpenShift Container Platform Developer console to create Tekton resources, view logs of pipeline runs, and manage pipelines in your OpenShift Container Platform namespaces. 2.2. OpenShift Pipelines Concepts This guide provides a detailed view of the various pipeline concepts. 2.2.1. Tasks Task resources are the building blocks of a pipeline and consist of sequentially executed steps. It is essentially a function of inputs and outputs. A task can run individually or as a part of the pipeline. Tasks are reusable and can be used in multiple pipelines. Steps are a series of commands that are sequentially executed by the task and achieve a specific goal, such as building an image. Every task runs as a pod, and each step runs as a container within that pod. Because steps run within the same pod, they can access the same volumes for caching files, config maps, and secrets. The following example shows the apply-manifests task. apiVersion: tekton.dev/v1 1 kind: Task 2 metadata: name: apply-manifests 3 spec: 4 workspaces: - name: source params: - name: manifest_dir description: The directory in source that contains yaml manifests type: string default: "k8s" steps: - name: apply image: image-registry.openshift-image-registry.svc:5000/openshift/cli:latest workingDir: /workspace/source command: ["/bin/bash", "-c"] args: - |- echo Applying manifests in USD(params.manifest_dir) directory oc apply -f USD(params.manifest_dir) echo ----------------------------------- 1 The task API version, v1 . 2 The type of Kubernetes object, Task . 3 The unique name of this task. 4 The list of parameters and steps in the task and the workspace used by the task. This task starts the pod and runs a container inside that pod using the specified image to run the specified commands. Note Starting with OpenShift Pipelines 1.6, the following defaults from the step YAML file are removed: The HOME environment variable does not default to the /tekton/home directory The workingDir field does not default to the /workspace directory Instead, the container for the step defines the HOME environment variable and the workingDir field. However, you can override the default values by specifying the custom values in the YAML file for the step. As a temporary measure, to maintain backward compatibility with the older OpenShift Pipelines versions, you can set the following fields in the TektonConfig custom resource definition to false : 2.2.2. When expression When expressions guard task execution by setting criteria for the execution of tasks within a pipeline. They contain a list of components that allows a task to run only when certain criteria are met. When expressions are also supported in the final set of tasks that are specified using the finally field in the pipeline YAML file. The key components of a when expression are as follows: input : Specifies static inputs or variables such as a parameter, task result, and execution status. You must enter a valid input. If you do not enter a valid input, its value defaults to an empty string. operator : Specifies the relationship of an input to a set of values . Enter in or notin as your operator values. values : Specifies an array of string values. Enter a non-empty array of static values or variables such as parameters, results, and a bound state of a workspace. The declared when expressions are evaluated before the task is run. If the value of a when expression is True , the task is run. If the value of a when expression is False , the task is skipped. You can use the when expressions in various use cases. For example, whether: The result of a task is as expected. A file in a Git repository has changed in the commits. An image exists in the registry. An optional workspace is available. The following example shows the when expressions for a pipeline run. The pipeline run will execute the create-file task only if the following criteria are met: the path parameter is README.md , and the echo-file-exists task executed only if the exists result from the check-file task is yes . apiVersion: tekton.dev/v1 kind: PipelineRun 1 metadata: generateName: guarded-pr- spec: taskRunTemplate: serviceAccountName: pipeline pipelineSpec: params: - name: path type: string description: The path of the file to be created workspaces: - name: source description: | This workspace is shared among all the pipeline tasks to read/write common resources tasks: - name: create-file 2 when: - input: "USD(params.path)" operator: in values: ["README.md"] workspaces: - name: source workspace: source taskSpec: workspaces: - name: source description: The workspace to create the readme file in steps: - name: write-new-stuff image: ubuntu script: 'touch USD(workspaces.source.path)/README.md' - name: check-file params: - name: path value: "USD(params.path)" workspaces: - name: source workspace: source runAfter: - create-file taskSpec: params: - name: path workspaces: - name: source description: The workspace to check for the file results: - name: exists description: indicates whether the file exists or is missing steps: - name: check-file image: alpine script: | if test -f USD(workspaces.source.path)/USD(params.path); then printf yes | tee /tekton/results/exists else printf no | tee /tekton/results/exists fi - name: echo-file-exists when: 3 - input: "USD(tasks.check-file.results.exists)" operator: in values: ["yes"] taskSpec: steps: - name: echo image: ubuntu script: 'echo file exists' ... - name: task-should-be-skipped-1 when: 4 - input: "USD(params.path)" operator: notin values: ["README.md"] taskSpec: steps: - name: echo image: ubuntu script: exit 1 ... finally: - name: finally-task-should-be-executed when: 5 - input: "USD(tasks.echo-file-exists.status)" operator: in values: ["Succeeded"] - input: "USD(tasks.status)" operator: in values: ["Succeeded"] - input: "USD(tasks.check-file.results.exists)" operator: in values: ["yes"] - input: "USD(params.path)" operator: in values: ["README.md"] taskSpec: steps: - name: echo image: ubuntu script: 'echo finally done' params: - name: path value: README.md workspaces: - name: source volumeClaimTemplate: spec: accessModes: - ReadWriteOnce resources: requests: storage: 16Mi 1 Specifies the type of Kubernetes object. In this example, PipelineRun . 2 Task create-file used in the pipeline. 3 when expression that specifies to execute the echo-file-exists task only if the exists result from the check-file task is yes . 4 when expression that specifies to skip the task-should-be-skipped-1 task only if the path parameter is README.md . 5 when expression that specifies to execute the finally-task-should-be-executed task only if the execution status of the echo-file-exists task and the task status is Succeeded , the exists result from the check-file task is yes , and the path parameter is README.md . The Pipeline Run details page of the OpenShift Container Platform web console shows the status of the tasks and when expressions as follows: All the criteria are met: Tasks and the when expression symbol, which is represented by a diamond shape are green. Any one of the criteria are not met: Task is skipped. Skipped tasks and the when expression symbol are grey. None of the criteria are met: Task is skipped. Skipped tasks and the when expression symbol are grey. Task run fails: Failed tasks and the when expression symbol are red. 2.2.3. Finally tasks The finally tasks are the final set of tasks specified using the finally field in the pipeline YAML file. A finally task always executes the tasks within the pipeline, irrespective of whether the pipeline runs are executed successfully. The finally tasks are executed in parallel after all the pipeline tasks are run, before the corresponding pipeline exits. You can configure a finally task to consume the results of any task within the same pipeline. This approach does not change the order in which this final task is run. It is executed in parallel with other final tasks after all the non-final tasks are executed. The following example shows a code snippet of the clone-cleanup-workspace pipeline. This code clones the repository into a shared workspace and cleans up the workspace. After executing the pipeline tasks, the cleanup task specified in the finally section of the pipeline YAML file cleans up the workspace. apiVersion: tekton.dev/v1 kind: Pipeline metadata: name: clone-cleanup-workspace 1 spec: workspaces: - name: git-source 2 tasks: - name: clone-app-repo 3 taskRef: name: git-clone-from-catalog params: - name: url value: https://github.com/tektoncd/community.git - name: subdirectory value: application workspaces: - name: output workspace: git-source finally: - name: cleanup 4 taskRef: 5 name: cleanup-workspace workspaces: 6 - name: source workspace: git-source - name: check-git-commit params: 7 - name: commit value: USD(tasks.clone-app-repo.results.commit) taskSpec: 8 params: - name: commit steps: - name: check-commit-initialized image: alpine script: | if [[ ! USD(params.commit) ]]; then exit 1 fi 1 Unique name of the pipeline. 2 The shared workspace where the git repository is cloned. 3 The task to clone the application repository to the shared workspace. 4 The task to clean-up the shared workspace. 5 A reference to the task that is to be executed in the task run. 6 A shared storage volume that a task in a pipeline needs at runtime to receive input or provide output. 7 A list of parameters required for a task. If a parameter does not have an implicit default value, you must explicitly set its value. 8 Embedded task definition. 2.2.4. TaskRun A TaskRun instantiates a task for execution with specific inputs, outputs, and execution parameters on a cluster. It can be invoked on its own or as part of a pipeline run for each task in a pipeline. A task consists of one or more steps that execute container images, and each container image performs a specific piece of build work. A task run executes the steps in a task in the specified order, until all steps execute successfully or a failure occurs. A TaskRun is automatically created by a PipelineRun for each task in a pipeline. The following example shows a task run that runs the apply-manifests task with the relevant input parameters: apiVersion: tekton.dev/v1 1 kind: TaskRun 2 metadata: name: apply-manifests-taskrun 3 spec: 4 taskRunTemplate: serviceAccountName: pipeline taskRef: 5 kind: Task name: apply-manifests workspaces: 6 - name: source persistentVolumeClaim: claimName: source-pvc 1 The task run API version v1 . 2 Specifies the type of Kubernetes object. In this example, TaskRun . 3 Unique name to identify this task run. 4 Definition of the task run. For this task run, the task and the required workspace are specified. 5 Name of the task reference used for this task run. This task run executes the apply-manifests task. 6 Workspace used by the task run. 2.2.5. Pipelines A Pipeline is a collection of Task resources arranged in a specific order of execution. They are executed to construct complex workflows that automate the build, deployment and delivery of applications. You can define a CI/CD workflow for your application using pipelines containing one or more tasks. A Pipeline resource definition consists of a number of fields or attributes, which together enable the pipeline to accomplish a specific goal. Each Pipeline resource definition must contain at least one Task resource, which ingests specific inputs and produces specific outputs. The pipeline definition can also optionally include Conditions , Workspaces , Parameters , or Resources depending on the application requirements. The following example shows the build-and-deploy pipeline, which builds an application image from a Git repository using the buildah task provided in the openshift-pipelines namespace: apiVersion: tekton.dev/v1 1 kind: Pipeline 2 metadata: name: build-and-deploy 3 spec: 4 workspaces: 5 - name: shared-workspace params: 6 - name: deployment-name type: string description: name of the deployment to be patched - name: git-url type: string description: url of the git repo for the code of deployment - name: git-revision type: string description: revision to be used from repo of the code for deployment default: "pipelines-1.18" - name: IMAGE type: string description: image to be built from the code tasks: 7 - name: fetch-repository taskRef: resolver: cluster params: - name: kind value: task - name: name value: git-clone - name: namespace value: openshift-pipelines workspaces: - name: output workspace: shared-workspace params: - name: URL value: USD(params.git-url) - name: SUBDIRECTORY value: "" - name: DELETE_EXISTING value: "true" - name: REVISION value: USD(params.git-revision) - name: build-image 8 taskRef: resolver: cluster params: - name: kind value: task - name: name value: buildah - name: namespace value: openshift-pipelines workspaces: - name: source workspace: shared-workspace params: - name: TLSVERIFY value: "false" - name: IMAGE value: USD(params.IMAGE) runAfter: - fetch-repository - name: apply-manifests 9 taskRef: name: apply-manifests workspaces: - name: source workspace: shared-workspace runAfter: 10 - build-image - name: update-deployment taskRef: name: update-deployment workspaces: - name: source workspace: shared-workspace params: - name: deployment value: USD(params.deployment-name) - name: IMAGE value: USD(params.IMAGE) runAfter: - apply-manifests 1 Pipeline API version v1 . 2 Specifies the type of Kubernetes object. In this example, Pipeline . 3 Unique name of this pipeline. 4 Specifies the definition and structure of the pipeline. 5 Workspaces used across all the tasks in the pipeline. 6 Parameters used across all the tasks in the pipeline. 7 Specifies the list of tasks used in the pipeline. 8 Task build-image , which uses the buildah task provided in the openshift-pipelines namespace to build application images from a given Git repository. 9 Task apply-manifests , which uses a user-defined task with the same name. 10 Specifies the sequence in which tasks are run in a pipeline. In this example, the apply-manifests task is run only after the build-image task is completed. Note The Red Hat OpenShift Pipelines Operator installs the Buildah task in the openshift-pipelines namespace and creates the pipeline service account with sufficient permission to build and push an image. The Buildah task can fail when associated with a different service account with insufficient permissions. 2.2.6. PipelineRun A PipelineRun is a type of resource that binds a pipeline, workspaces, credentials, and a set of parameter values specific to a scenario to run the CI/CD workflow. A pipeline run is the running instance of a pipeline. It instantiates a pipeline for execution with specific inputs, outputs, and execution parameters on a cluster. It also creates a task run for each task in the pipeline run. The pipeline runs the tasks sequentially until they are complete or a task fails. The status field tracks and the progress of each task run and stores it for monitoring and auditing purposes. The following example runs the build-and-deploy pipeline with relevant resources and parameters: apiVersion: tekton.dev/v1 1 kind: PipelineRun 2 metadata: name: build-deploy-api-pipelinerun 3 spec: pipelineRef: name: build-and-deploy 4 params: 5 - name: deployment-name value: vote-api - name: git-url value: https://github.com/openshift-pipelines/vote-api.git - name: IMAGE value: image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/vote-api workspaces: 6 - name: shared-workspace volumeClaimTemplate: spec: accessModes: - ReadWriteOnce resources: requests: storage: 500Mi 1 Pipeline run API version v1 . 2 The type of Kubernetes object. In this example, PipelineRun . 3 Unique name to identify this pipeline run. 4 Name of the pipeline to be run. In this example, build-and-deploy . 5 The list of parameters required to run the pipeline. 6 Workspace used by the pipeline run. Additional resources Authenticating pipelines with repositories using secrets 2.2.7. Pod templates Optionally, you can define a pod template in a PipelineRun or TaskRun custom resource (CR). You can use any parameters available for a Pod CR in the pod template. When creating pods for executing the pipeline or task, OpenShift Pipelines sets these parameters for every pod. For example, you can use a pod template to make the pod execute as a user and not as root. For a pipeline run, you can define a pod template in the pipelineRunTemplate.podTemplate spec, as in the following example: Example PipelineRun CR with a pod template apiVersion: tekton.dev/v1 kind: PipelineRun metadata: name: mypipelinerun spec: pipelineRef: name: mypipeline taskRunTemplate: podTemplate: securityContext: runAsNonRoot: true runAsUser: 1001 Note In the earlier API version v1beta1 , the pod template for a PipelineRun CR was specified as podTemplate directly in the spec: section. This format is not supported in the v1 API. For a task run, you can define a pod template in the podTemplate spec, as in the following example: Example TaskRun CR with a pod template apiVersion: tekton.dev/v1 # or tekton.dev/v1beta1 kind: TaskRun metadata: name: mytaskrun namespace: default spec: taskRef: name: mytask podTemplate: schedulerName: volcano securityContext: runAsNonRoot: true runAsUser: 1001 Additional resources Using pods 2.2.8. Workspaces Note It is recommended that you use workspaces instead of the PipelineResource CRs in Red Hat OpenShift Pipelines, as PipelineResource CRs are difficult to debug, limited in scope, and make tasks less reusable. Workspaces declare shared storage volumes that a task in a pipeline needs at runtime to receive input or provide output. Instead of specifying the actual location of the volumes, workspaces enable you to declare the filesystem or parts of the filesystem that would be required at runtime. A task or pipeline declares the workspace and you must provide the specific location details of the volume. It is then mounted into that workspace in a task run or a pipeline run. This separation of volume declaration from runtime storage volumes makes the tasks reusable, flexible, and independent of the user environment. With workspaces, you can: Store task inputs and outputs Share data among tasks Use it as a mount point for credentials held in secrets Use it as a mount point for configurations held in config maps Use it as a mount point for common tools shared by an organization Create a cache of build artifacts that speed up jobs You can specify workspaces in the TaskRun or PipelineRun using: A read-only config map or secret An existing persistent volume claim shared with other tasks A persistent volume claim from a provided volume claim template An emptyDir that is discarded when the task run completes The following example shows a code snippet of the build-and-deploy pipeline, which declares a shared-workspace workspace for the build-image and apply-manifests tasks as defined in the pipeline. apiVersion: tekton.dev/v1 kind: Pipeline metadata: name: build-and-deploy spec: workspaces: 1 - name: shared-workspace params: ... tasks: 2 - name: build-image taskRef: resolver: cluster params: - name: kind value: task - name: name value: buildah - name: namespace value: openshift-pipelines workspaces: 3 - name: source 4 workspace: shared-workspace 5 params: - name: TLSVERIFY value: "false" - name: IMAGE value: USD(params.IMAGE) runAfter: - fetch-repository - name: apply-manifests taskRef: name: apply-manifests workspaces: 6 - name: source workspace: shared-workspace runAfter: - build-image ... 1 List of workspaces shared between the tasks defined in the pipeline. A pipeline can define as many workspaces as required. In this example, only one workspace named shared-workspace is declared. 2 Definition of tasks used in the pipeline. This snippet defines two tasks, build-image and apply-manifests , which share a common workspace. 3 List of workspaces used in the build-image task. A task definition can include as many workspaces as it requires. However, it is recommended that a task uses at most one writable workspace. 4 Name that uniquely identifies the workspace used in the task. This task uses one workspace named source . 5 Name of the pipeline workspace used by the task. Note that the workspace source in turn uses the pipeline workspace named shared-workspace . 6 List of workspaces used in the apply-manifests task. Note that this task shares the source workspace with the build-image task. Workspaces help tasks share data, and allow you to specify one or more volumes that each task in the pipeline requires during execution. You can create a persistent volume claim or provide a volume claim template that creates a persistent volume claim for you. The following code snippet of the build-deploy-api-pipelinerun pipeline run uses a volume claim template to create a persistent volume claim for defining the storage volume for the shared-workspace workspace used in the build-and-deploy pipeline. apiVersion: tekton.dev/v1 kind: PipelineRun metadata: name: build-deploy-api-pipelinerun spec: pipelineRef: name: build-and-deploy params: ... workspaces: 1 - name: shared-workspace 2 volumeClaimTemplate: 3 spec: accessModes: - ReadWriteOnce resources: requests: storage: 500Mi 1 Specifies the list of pipeline workspaces for which volume binding will be provided in the pipeline run. 2 The name of the workspace in the pipeline for which the volume is being provided. 3 Specifies a volume claim template that creates a persistent volume claim to define the storage volume for the workspace. 2.2.9. Step actions A step is a part of a task. If you define a step in a task, you cannot reference this step from another task. However, you can optionally define a step action in a StepAction custom resource (CR). This CR contains the action that a step performs. You can reference a StepAction object from a step to create a step that performs the action. You can also use resolvers to reference a StepAction definition that is available from an external source. The following examples shows a StepAction CR named apply-manifests-action . This step action applies manifests from a source tree to your OpenShift Container Platform environment: apiVersion: tekton.dev/v1 kind: StepAction metadata: name: apply-manifests-action spec: params: - name: working_dir description: The working directory where the source is located type: string 1 default: "/workspace/source" - name: manifest_dir description: The directory in source that contains yaml manifests default: "k8s" results: - name: output description: The output of the oc apply command image: image-registry.openshift-image-registry.svc:5000/openshift/cli:latest env: - name: MANIFEST_DIR value: USD(params.manifest_dir) workingDir: USD(params.working_dir) script: | #!/usr/bin/env bash oc apply -f "USDMANIFEST_DIR" | tee USD(results.output) 1 The type specification for a parameter is optional. The StepAction CR does not include definitions of workspaces. Instead, the step action expects that the task that includes the action also provides the mounted source tree, typically using a workspace. A StepAction object can define parameters and results. When you reference this object, you must specify the values for the parameters of the StepAction object in the definition of the step. The results of the StepAction object automatically become the results of the step. Important To avoid malicious attacks that use the shell, the StepAction CR does not support using parameter values in a script value. Instead, you must use the env: section to define environment variables that contain the parameter values. The following example task includes a step that references the apply-manifests-action step action, provides the necessary parameters, and uses the result: apiVersion: tekton.dev/v1 kind: Task metadata: name: apply-manifests-with-action spec: workspaces: - name: source params: - name: manifest_dir description: The directory in source that contains yaml manifests type: string default: "k8s" steps: - name: apply ref: name: apply-manifests-action params: - name: working_dir value: "/workspace/source" - name: manifest_dir value: USD(params.manifest_dir) - name: display_result script: 'echo USD(step.apply.results.output)' Additional resources Specifying remote pipelines, tasks, and step actions using resolvers 2.2.10. Triggers Use Triggers in conjunction with pipelines to create a full-fledged CI/CD system where Kubernetes resources define the entire CI/CD execution. Triggers capture the external events, such as a Git pull request, and process them to extract key pieces of information. Mapping this event data to a set of predefined parameters triggers a series of tasks that can then create and deploy Kubernetes resources and instantiate the pipeline. For example, you define a CI/CD workflow using Red Hat OpenShift Pipelines for your application. The pipeline must start for any new changes to take effect in the application repository. Triggers automate this process by capturing and processing any change event and by triggering a pipeline run that deploys the new image with the latest changes. Triggers consist of the following main resources that work together to form a reusable, decoupled, and self-sustaining CI/CD system: The TriggerBinding resource extracts the fields from an event payload and stores them as parameters. The following example shows a code snippet of the TriggerBinding resource, which extracts the Git repository information from the received event payload: apiVersion: triggers.tekton.dev/v1beta1 1 kind: TriggerBinding 2 metadata: name: vote-app 3 spec: params: 4 - name: git-repo-url value: USD(body.repository.url) - name: git-repo-name value: USD(body.repository.name) - name: git-revision value: USD(body.head_commit.id) 1 The API version of the TriggerBinding resource. In this example, v1beta1 . 2 Specifies the type of Kubernetes object. In this example, TriggerBinding . 3 Unique name to identify the TriggerBinding resource. 4 List of parameters which will be extracted from the received event payload and passed to the TriggerTemplate resource. In this example, the Git repository URL, name, and revision are extracted from the body of the event payload. The TriggerTemplate resource acts as a standard for the way resources must be created. It specifies the way parameterized data from the TriggerBinding resource should be used. A trigger template receives input from the trigger binding, and then performs a series of actions that results in creation of new pipeline resources, and initiation of a new pipeline run. The following example shows a code snippet of a TriggerTemplate resource, which creates a pipeline run using the Git repository information received from the TriggerBinding resource you just created: apiVersion: triggers.tekton.dev/v1beta1 1 kind: TriggerTemplate 2 metadata: name: vote-app 3 spec: params: 4 - name: git-repo-url description: The git repository url - name: git-revision description: The git revision default: pipelines-1.18 - name: git-repo-name description: The name of the deployment to be created / patched resourcetemplates: 5 - apiVersion: tekton.dev/v1 kind: PipelineRun metadata: name: build-deploy-USD(tt.params.git-repo-name)-USD(uid) spec: taskRunTemplate: serviceAccountName: pipeline pipelineRef: name: build-and-deploy params: - name: deployment-name value: USD(tt.params.git-repo-name) - name: git-url value: USD(tt.params.git-repo-url) - name: git-revision value: USD(tt.params.git-revision) - name: IMAGE value: image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/USD(tt.params.git-repo-name) workspaces: - name: shared-workspace volumeClaimTemplate: spec: accessModes: - ReadWriteOnce resources: requests: storage: 500Mi 1 The API version of the TriggerTemplate resource. In this example, v1beta1 . 2 Specifies the type of Kubernetes object. In this example, TriggerTemplate . 3 Unique name to identify the TriggerTemplate resource. 4 Parameters supplied by the TriggerBinding resource. 5 List of templates that specify the way resources must be created using the parameters received through the TriggerBinding or EventListener resources. The Trigger resource combines the TriggerBinding and TriggerTemplate resources, and optionally, the interceptors event processor. Interceptors process all the events for a specific platform that runs before the TriggerBinding resource. You can use interceptors to filter the payload, verify events, define and test trigger conditions, and implement other useful processing. Interceptors use secret for event verification. After the event data passes through an interceptor, it then goes to the trigger before you pass the payload data to the trigger binding. You can also use an interceptor to modify the behavior of the associated trigger referenced in the EventListener specification. The following example shows a code snippet of a Trigger resource, named vote-trigger that connects the TriggerBinding and TriggerTemplate resources, and the interceptors event processor. apiVersion: triggers.tekton.dev/v1beta1 1 kind: Trigger 2 metadata: name: vote-trigger 3 spec: taskRunTemplate: serviceAccountName: pipeline 4 interceptors: - ref: name: "github" 5 params: 6 - name: "secretRef" value: secretName: github-secret secretKey: secretToken - name: "eventTypes" value: ["push"] bindings: - ref: vote-app 7 template: 8 ref: vote-app --- apiVersion: v1 kind: Secret 9 metadata: name: github-secret type: Opaque stringData: secretToken: "1234567" 1 The API version of the Trigger resource. In this example, v1beta1 . 2 Specifies the type of Kubernetes object. In this example, Trigger . 3 Unique name to identify the Trigger resource. 4 Service account name to be used. 5 Interceptor name to be referenced. In this example, github . 6 Desired parameters to be specified. 7 Name of the TriggerBinding resource to be connected to the TriggerTemplate resource. 8 Name of the TriggerTemplate resource to be connected to the TriggerBinding resource. 9 Secret to be used to verify events. The EventListener resource provides an endpoint, or an event sink, that listens for incoming HTTP-based events with a JSON payload. It extracts event parameters from each TriggerBinding resource, and then processes this data to create Kubernetes resources as specified by the corresponding TriggerTemplate resource. The EventListener resource also performs lightweight event processing or basic filtering on the payload using event interceptors , which identify the type of payload and optionally modify it. Currently, pipeline triggers support five types of interceptors: Webhook Interceptors , GitHub Interceptors , GitLab Interceptors , Bitbucket Interceptors , and Common Expression Language (CEL) Interceptors . The following example shows an EventListener resource, which references the Trigger resource named vote-trigger . apiVersion: triggers.tekton.dev/v1beta1 1 kind: EventListener 2 metadata: name: vote-app 3 spec: taskRunTemplate: serviceAccountName: pipeline 4 triggers: - triggerRef: vote-trigger 5 1 The API version of the EventListener resource. In this example, v1beta1 . 2 Specifies the type of Kubernetes object. In this example, EventListener . 3 Unique name to identify the EventListener resource. 4 Service account name to be used. 5 Name of the Trigger resource referenced by the EventListener resource. 2.3. Additional resources For information on installing OpenShift Pipelines, see Installing OpenShift Pipelines . For more details on creating custom CI/CD solutions, see Creating CI/CD solutions for applications using OpenShift Pipelines . For more details on re-encrypt TLS termination, see Re-encryption Termination . For more details on secured routes, see the Secured routes section.

Commands:
apiVersion: tekton.dev/v1 1 kind: Task 2 metadata: name: apply-manifests 3 spec: 4 workspaces: - name: source params: - name: manifest_dir description: The directory in source that contains yaml manifests type: string default: "k8s" steps: - name: apply image: image-registry.openshift-image-registry.svc:5000/openshift/cli:latest workingDir: /workspace/source command: ["/bin/bash", "-c"] args: - |- echo Applying manifests in USD(params.manifest_dir) directory oc apply -f USD(params.manifest_dir) echo -----------------------------------
spec: pipeline: disable-working-directory-overwrite: false disable-home-env-overwrite: false
apiVersion: tekton.dev/v1 kind: PipelineRun 1 metadata: generateName: guarded-pr- spec: taskRunTemplate: serviceAccountName: pipeline pipelineSpec: params: - name: path type: string description: The path of the file to be created workspaces: - name: source description: | This workspace is shared among all the pipeline tasks to read/write common resources tasks: - name: create-file 2 when: - input: "USD(params.path)" operator: in values: ["README.md"] workspaces: - name: source workspace: source taskSpec: workspaces: - name: source description: The workspace to create the readme file in steps: - name: write-new-stuff image: ubuntu script: 'touch USD(workspaces.source.path)/README.md' - name: check-file params: - name: path value: "USD(params.path)" workspaces: - name: source workspace: source runAfter: - create-file taskSpec: params: - name: path workspaces: - name: source description: The workspace to check for the file results: - name: exists description: indicates whether the file exists or is missing steps: - name: check-file image: alpine script: | if test -f USD(workspaces.source.path)/USD(params.path); then printf yes | tee /tekton/results/exists else printf no | tee /tekton/results/exists fi - name: echo-file-exists when: 3 - input: "USD(tasks.check-file.results.exists)" operator: in values: ["yes"] taskSpec: steps: - name: echo image: ubuntu script: 'echo file exists' - name: task-should-be-skipped-1 when: 4 - input: "USD(params.path)" operator: notin values: ["README.md"] taskSpec: steps: - name: echo image: ubuntu script: exit 1 finally: - name: finally-task-should-be-executed when: 5 - input: "USD(tasks.echo-file-exists.status)" operator: in values: ["Succeeded"] - input: "USD(tasks.status)" operator: in values: ["Succeeded"] - input: "USD(tasks.check-file.results.exists)" operator: in values: ["yes"] - input: "USD(params.path)" operator: in values: ["README.md"] taskSpec: steps: - name: echo image: ubuntu script: 'echo finally done' params: - name: path value: README.md workspaces: - name: source volumeClaimTemplate: spec: accessModes: - ReadWriteOnce resources: requests: storage: 16Mi
apiVersion: tekton.dev/v1 kind: Pipeline metadata: name: clone-cleanup-workspace 1 spec: workspaces: - name: git-source 2 tasks: - name: clone-app-repo 3 taskRef: name: git-clone-from-catalog params: - name: url value: https://github.com/tektoncd/community.git - name: subdirectory value: application workspaces: - name: output workspace: git-source finally: - name: cleanup 4 taskRef: 5 name: cleanup-workspace workspaces: 6 - name: source workspace: git-source - name: check-git-commit params: 7 - name: commit value: USD(tasks.clone-app-repo.results.commit) taskSpec: 8 params: - name: commit steps: - name: check-commit-initialized image: alpine script: | if [[ ! USD(params.commit) ]]; then exit 1 fi
apiVersion: tekton.dev/v1 1 kind: TaskRun 2 metadata: name: apply-manifests-taskrun 3 spec: 4 taskRunTemplate: serviceAccountName: pipeline taskRef: 5 kind: Task name: apply-manifests workspaces: 6 - name: source persistentVolumeClaim: claimName: source-pvc
apiVersion: tekton.dev/v1 1 kind: Pipeline 2 metadata: name: build-and-deploy 3 spec: 4 workspaces: 5 - name: shared-workspace params: 6 - name: deployment-name type: string description: name of the deployment to be patched - name: git-url type: string description: url of the git repo for the code of deployment - name: git-revision type: string description: revision to be used from repo of the code for deployment default: "pipelines-1.18" - name: IMAGE type: string description: image to be built from the code tasks: 7 - name: fetch-repository taskRef: resolver: cluster params: - name: kind value: task - name: name value: git-clone - name: namespace value: openshift-pipelines workspaces: - name: output workspace: shared-workspace params: - name: URL value: USD(params.git-url) - name: SUBDIRECTORY value: "" - name: DELETE_EXISTING value: "true" - name: REVISION value: USD(params.git-revision) - name: build-image 8 taskRef: resolver: cluster params: - name: kind value: task - name: name value: buildah - name: namespace value: openshift-pipelines workspaces: - name: source workspace: shared-workspace params: - name: TLSVERIFY value: "false" - name: IMAGE value: USD(params.IMAGE) runAfter: - fetch-repository - name: apply-manifests 9 taskRef: name: apply-manifests workspaces: - name: source workspace: shared-workspace runAfter: 10 - build-image - name: update-deployment taskRef: name: update-deployment workspaces: - name: source workspace: shared-workspace params: - name: deployment value: USD(params.deployment-name) - name: IMAGE value: USD(params.IMAGE) runAfter: - apply-manifests
apiVersion: tekton.dev/v1 1 kind: PipelineRun 2 metadata: name: build-deploy-api-pipelinerun 3 spec: pipelineRef: name: build-and-deploy 4 params: 5 - name: deployment-name value: vote-api - name: git-url value: https://github.com/openshift-pipelines/vote-api.git - name: IMAGE value: image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/vote-api workspaces: 6 - name: shared-workspace volumeClaimTemplate: spec: accessModes: - ReadWriteOnce resources: requests: storage: 500Mi
apiVersion: tekton.dev/v1 kind: PipelineRun metadata: name: mypipelinerun spec: pipelineRef: name: mypipeline taskRunTemplate: podTemplate: securityContext: runAsNonRoot: true runAsUser: 1001
apiVersion: tekton.dev/v1 # or tekton.dev/v1beta1 kind: TaskRun metadata: name: mytaskrun namespace: default spec: taskRef: name: mytask podTemplate: schedulerName: volcano securityContext: runAsNonRoot: true runAsUser: 1001
apiVersion: tekton.dev/v1 kind: Pipeline metadata: name: build-and-deploy spec: workspaces: 1 - name: shared-workspace params: tasks: 2 - name: build-image taskRef: resolver: cluster params: - name: kind value: task - name: name value: buildah - name: namespace value: openshift-pipelines workspaces: 3 - name: source 4 workspace: shared-workspace 5 params: - name: TLSVERIFY value: "false" - name: IMAGE value: USD(params.IMAGE) runAfter: - fetch-repository - name: apply-manifests taskRef: name: apply-manifests workspaces: 6 - name: source workspace: shared-workspace runAfter: - build-image
apiVersion: tekton.dev/v1 kind: PipelineRun metadata: name: build-deploy-api-pipelinerun spec: pipelineRef: name: build-and-deploy params: workspaces: 1 - name: shared-workspace 2 volumeClaimTemplate: 3 spec: accessModes: - ReadWriteOnce resources: requests: storage: 500Mi
apiVersion: tekton.dev/v1 kind: StepAction metadata: name: apply-manifests-action spec: params: - name: working_dir description: The working directory where the source is located type: string 1 default: "/workspace/source" - name: manifest_dir description: The directory in source that contains yaml manifests default: "k8s" results: - name: output description: The output of the oc apply command image: image-registry.openshift-image-registry.svc:5000/openshift/cli:latest env: - name: MANIFEST_DIR value: USD(params.manifest_dir) workingDir: USD(params.working_dir) script: | #!/usr/bin/env bash oc apply -f "USDMANIFEST_DIR" | tee USD(results.output)
apiVersion: tekton.dev/v1 kind: Task metadata: name: apply-manifests-with-action spec: workspaces: - name: source params: - name: manifest_dir description: The directory in source that contains yaml manifests type: string default: "k8s" steps: - name: apply ref: name: apply-manifests-action params: - name: working_dir value: "/workspace/source" - name: manifest_dir value: USD(params.manifest_dir) - name: display_result script: 'echo USD(step.apply.results.output)'
apiVersion: triggers.tekton.dev/v1beta1 1 kind: TriggerBinding 2 metadata: name: vote-app 3 spec: params: 4 - name: git-repo-url value: USD(body.repository.url) - name: git-repo-name value: USD(body.repository.name) - name: git-revision value: USD(body.head_commit.id)
apiVersion: triggers.tekton.dev/v1beta1 1 kind: TriggerTemplate 2 metadata: name: vote-app 3 spec: params: 4 - name: git-repo-url description: The git repository url - name: git-revision description: The git revision default: pipelines-1.18 - name: git-repo-name description: The name of the deployment to be created / patched resourcetemplates: 5 - apiVersion: tekton.dev/v1 kind: PipelineRun metadata: name: build-deploy-USD(tt.params.git-repo-name)-USD(uid) spec: taskRunTemplate: serviceAccountName: pipeline pipelineRef: name: build-and-deploy params: - name: deployment-name value: USD(tt.params.git-repo-name) - name: git-url value: USD(tt.params.git-repo-url) - name: git-revision value: USD(tt.params.git-revision) - name: IMAGE value: image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/USD(tt.params.git-repo-name) workspaces: - name: shared-workspace volumeClaimTemplate: spec: accessModes: - ReadWriteOnce resources: requests: storage: 500Mi
apiVersion: triggers.tekton.dev/v1beta1 1 kind: Trigger 2 metadata: name: vote-trigger 3 spec: taskRunTemplate: serviceAccountName: pipeline 4 interceptors: - ref: name: "github" 5 params: 6 - name: "secretRef" value: secretName: github-secret secretKey: secretToken - name: "eventTypes" value: ["push"] bindings: - ref: vote-app 7 template: 8 ref: vote-app --- apiVersion: v1 kind: Secret 9 metadata: name: github-secret type: Opaque stringData: secretToken: "1234567"
apiVersion: triggers.tekton.dev/v1beta1 1 kind: EventListener 2 metadata: name: vote-app 3 spec: taskRunTemplate: serviceAccountName: pipeline 4 triggers: - triggerRef: vote-trigger 5