Soon, all Red Hat OpenShift documentation will only be available on docs.redhat.com, the official location of all Red Hat product documentation. Get familiar with the updated experience today!
  1. Documentation
    2. history
×

Migrating from Jenkins to Tekton

Jenkins and Tekton are extensively used to automate the process of building, testing, and deploying applications and projects. However, Tekton is a cloud-native CI/CD solution that works seamlessly with Kubernetes and OpenShift Container Platform. This document helps you migrate your Jenkins CI/CD workflows to Tekton.

Comparison of Jenkins and Tekton concepts

This section summarizes the basic terms used in Jenkins and Tekton, and compares the equivalent terms.

Jenkins terminology

Jenkins offers declarative and scripted pipelines that are extensible using shared libraries and plugins. Some basic terms in Jenkins are as follows:

  • Pipeline: Automates the entire process of building, testing, and deploying applications, using the Groovy syntax.

  • Node: A machine capable of either orchestrating or executing a scripted pipeline.

  • Stage: A conceptually distinct subset of tasks performed in a pipeline. Plugins or user interfaces often use this block to display status or progress of tasks.

  • Step: A single task that specifies the exact action to be taken, either by using a command or a script.

Tekton terminology

Tekton uses the YAML syntax for declarative pipelines and consists of tasks. Some basic terms in Tekton are as follows:

  • Pipeline: A set of tasks in a series, in parallel, or both.

  • Task: A sequence of steps as commands, binaries, or scripts.

  • PipelineRun: Execution of a pipeline with one or more tasks.

  • TaskRun: Execution of a task with one or more steps.

    You can initiate a PipelineRun or a TaskRun with a set of inputs such as parameters and workspaces, and the execution results in a set of outputs and artifacts.

  • Workspace: In Tekton, workspaces are conceptual blocks that serve the following purposes:

    • Storage of inputs, outputs, and build artifacts.

    • Common space to share data among tasks.

    • Mount points for credentials held in secrets, configurations held in config maps, and common tools shared by an organization.

    In Jenkins, there is no direct equivalent of Tekton workspaces. You can think of the control node as a workspace, as it stores the cloned code repository, build history, and artifacts. In situations where a job is assigned to a different node, the cloned code and the generated artifacts are stored in that node, but the build history is maintained by the control node.

Mapping of concepts

The building blocks of Jenkins and Tekton are not equivalent, and a comparison does not provide a technically accurate mapping. The following terms and concepts in Jenkins and Tekton correlate in general:

Table 1. Jenkins and Tekton - basic comparison
Jenkins Tekton

Pipeline

Pipeline and PipelineRun

Stage

Task

Step

A step in a task

Migrating a sample pipeline from Jenkins to Tekton

This section provides equivalent examples of pipelines in Jenkins and Tekton and helps you to migrate your build, test, and deploy pipelines from Jenkins to Tekton.

Jenkins pipeline

Consider a Jenkins pipeline written in Groovy for building, testing, and deploying:

pipeline {
   agent any
   stages {
       stage('Build') {
           steps {
               sh 'make'
           }
       }
       stage('Test'){
           steps {
               sh 'make check'
               junit 'reports/**/*.xml'
           }
       }
       stage('Deploy') {
           steps {
               sh 'make publish'
           }
       }
   }
}

Tekton pipeline

In Tekton, the equivalent example of the Jenkins pipeline comprises of three tasks, each of which can be written declaratively using the YAML syntax:

Example build task
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: myproject-build
spec:
  workspaces:
  - name: source
  steps:
  - image: my-ci-image
    command: ["make"]
    workingDir: $(workspaces.source.path)
Example test task:
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: myproject-test
spec:
  workspaces:
  - name: source
  steps:
  - image: my-ci-image
    command: ["make check"]
    workingDir: $(workspaces.source.path)
  - image: junit-report-image
    script: |
      #!/usr/bin/env bash
      junit-report reports/**/*.xml
    workingDir: $(workspaces.source.path)
Example deploy task:
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: myprojectd-deploy
spec:
  workspaces:
  - name: source
  steps:
  - image: my-deploy-image
    command: ["make deploy"]
    workingDir: $(workspaces.source.path)

You can combine the three tasks sequentially to form a Tekton pipeline:

Example: Tekton pipeline for building, testing, and deployment
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: myproject-pipeline
spec:
  workspaces:
  - name: shared-dir
  tasks:
  - name: build
    taskRef:
      name: myproject-build
    workspaces:
    - name: source
      workspace: shared-dir
  - name: test
    taskRef:
      name: myproject-test
    workspaces:
    - name: source
      workspace: shared-dir
  - name: deploy
    taskRef:
      name: myproject-deploy
    workspaces:
    - name: source
      workspace: shared-dir

Migrating from Jenkins plugins to Tekton Hub tasks

You can exend the capability of Jenkins by using plugins. To achieve similar extensibility in Tekton, use any of the available tasks from Tekton Hub.

As an example, consider the git-clone task available in the Tekton Hub, that corresponds to the git plugin for Jenkins.

Example: git-clone task from Tekton Hub
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
 name: demo-pipeline
spec:
 params:
   - name: repo_url
   - name: revision
 workspaces:
   - name: source
 tasks:
   - name: fetch-from-git
     taskRef:
       name: git-clone
     params:
       - name: url
         value: $(params.repo_url)
       - name: revision
         value: $(params.revision)
     workspaces:
     - name: output
       workspace: source

Extending Tekton capabilities using custom tasks and scripts

In Tekton, if you do not find the right task in Tekton Hub, or need greater control over tasks, you can create custom tasks and scripts to extend Tekton’s capabilities.

Example: Custom task for running the maven test command
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: maven-test
spec:
  workspaces:
  - name: source
  steps:
  - image: my-maven-image
    command: ["mvn test"]
    workingDir: $(workspaces.source.path)
Example: Execute a custom shell script by providing its path
...
steps:
  image: ubuntu
  script: |
      #!/usr/bin/env bash
      /workspace/my-script.sh
...
Example: Execute a custom Python script by writing it in the YAML file
...
steps:
  image: python
  script: |
      #!/usr/bin/env python3
      print(“hello from python!”)
...

Comparison of Jenkins and Tekton execution models

Jenkins and Tekton offer similar functions but are different in architecture and execution. This section outlines a brief comparison of the two execution models.

Table 2. Comparison of execution models in Jenkins and Tekton
Jenkins Tekton

Jenkins has a control node. Jenkins executes pipelines and steps centrally, or orchestrates jobs running in other nodes.

Tekton is serverless and distributed, and there is no central dependency for execution.

The containers are launched by the control node through the pipeline.

Tekton adopts a 'container-first' approach, where every step is executed as a container running in a pod (equivalent to nodes in Jenkins).

Extensibility is achieved using plugins.

Extensibility is achieved using tasks in Tekton Hub, or by creating custom tasks and scripts.