피드 구독

This document demonstrates passing information from one task to another in a Tekton pipeline. It provides all the steps needed, including YAML files, for a test use case demonstrating a simple way of passing information from one task to another in a Tekton pipeline. It starts from the basics, like creating a project and persistent volume creation (PVC), before building the task and pipeline. Finally, it includes the YAML files for the respective task and pipeline runs. You can extend this example for your own use cases.

I tested this example with Red Hat OpenShift Pipelines version 1.70 and higher, running on OpenShift Version 4.10 and higher. Confirm that the Red Hat OpenShift Pipelines operator is installed.

Create a test project

kind: Project
apiVersion: project.openshift.io/v1
metadata:
  name: test

 

Before you create tasks and pipeline, confirm that you have a PVC associated with the project where you are creating them.

Create a PVC named test

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: test
  namespace: test
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: gp2
  volumeMode: Filesystem

 

In the first task, add a workspace like the one in this spec. Use the workspace name source in this case to use in the second task. Capture what you need to pass in data as results and redirect that information to a file. For example, ee_data.json, which you call in the second task.

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: task1
spec:
  description: >-
    Add execution environment to automation controller
  workspaces:
    - name: source
      results:
        - name: data
          description: ID to be passed to next task
  steps:
    - name: task1
      image: quay.io/rshah/jq
      workingDir: $(workspaces.source.path)
      resources: {}
      script: |
        #!/usr/bin/env bash
        data="This is the output from task 1"
        printf "%s" "${data}" > ee_data.json
        AC_EE_ID=$(cat ee_data.json)
        printf "%s" ${AC_EE_ID}

 

In task 2, you can reference ee_data.json as shown below:


apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: task2
spec:
  workspaces:
    - name: source
  steps:
    - name: task2
      image: quay.io/rshah/jq
      workingDir: $(workspaces.source.path)
      resources: {}
      script: |
        #!/usr/bin/env bash
        AC_EE_ID=$(cat ee_data.json)
        printf "%s" ${AC_EE_ID}

 

When you run task1 and task2 in a pipeline, both tasks should print the same output.

Create a pipeline

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: "value_pass_pipeline"
spec:
  workspaces:
    - name: source
  params:
    - description: Verify the TLS on the registry endpoint (for push/pull to a non-TLS registry)
      name: TLSVERIFY
      type: string
      default: "false"
    - description: Dummy parameter for task1
      name: task1
      type: string
      default: "task1"
    - description: Dummy parameter for task2
      name: task2
      type: string
      default: "task2"
  tasks:
    - name: task1
      taskRef:
        kind: Task
        name: task1
      params:
        workspaces:
          - name: source
            workspace: source
    - name: task2
      taskRef:
        kind: Task
        name: task2
      params:
        runAfter:
          - task1
        workspaces:
          - name: source
            workspace: source

 

When you run the pipeline, both tasks will show the output shown below:

STEP-TASK1 This is the output from task 1
STEP-TASK2 This is the output from task 1

 

Task and pipeline runs

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: test-0ij91k-task1
  namespace: test
spec:
  resources: {}
  serviceAccountName: pipeline
  taskRef:
    kind: Task
    name: task1
  timeout: 59m59.989014151s
  workspaces:
    - name: source
      persistentVolumeClaim:
        claimName: test
---
apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: test-0ij91k-task2
  namespace: test
spec:
  resources: {}
  serviceAccountName: pipeline
  taskRef:
    kind: Task
    name: task2
  timeout: 59m59.989014151s
  workspaces:
    - name: source
      persistentVolumeClaim:
        claimName: test
---
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: test-0ij91k
  namespace: test
spec:
  pipelineRef:
    name: test
  serviceAccountName: pipeline
  timeout: 1h0m0s
  workspaces:
    - name: source
      persistentVolumeClaim:
        claimName: test

 

This simple example provides a basic understanding of passing output from one task as input to another. You can extend this to your use cases.


저자 소개

Ritesh Shah is a Principal Architect with the Red Hat Portfolio Technology Platform team and focuses on creating and using next-generation platforms, including artificial intelligence/machine learning (AI/ML) workloads, application modernization and deployment, Disaster Recovery and Business Continuity as well as software-defined data storage.

Ritesh is an advocate for open source technologies and products, focusing on modern platform architecture and design for critical business needs. He is passionate about next-generation platforms and how application teams, including data scientists, can use open source technologies to their advantage. Ritesh has vast experience working with and helping enterprises succeed with open source technologies.

Read full bio
UI_Icon-Red_Hat-Close-A-Black-RGB

채널별 검색

automation icon

오토메이션

기술, 팀, 인프라를 위한 IT 자동화 최신 동향

AI icon

인공지능

고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트

open hybrid cloud icon

오픈 하이브리드 클라우드

하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요

security icon

보안

환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보

edge icon

엣지 컴퓨팅

엣지에서의 운영을 단순화하는 플랫폼 업데이트

Infrastructure icon

인프라

세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보

application development icon

애플리케이션

복잡한 애플리케이션에 대한 솔루션 더 보기

Original series icon

오리지널 쇼

엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리