Creating a Pipeline

We will embark on a comprehensive journey through a complete pipeline, with each individual task covered in its tutorial. This approach aims to provide a detailed understanding of each task and how they collectively contribute to the functionality of pipeline-as-code.

In modern software development practices, pipelines play a crucial role in automating and streamlining the process of building, testing, and deploying applications. This tutorial will guide you through creating a pipeline using pipeline-as-code concepts. We'll focus on GitHub as the provider and assume you have a SAAP set up with pipeline-as-code capabilities.

Now that we have completed all the prerequisites to run this pipelineRun, we can continue by adding a pipeline to our application using pipeline-as-code approach.

Objectives

• Create a Tekton PipelineRun using a .tekton/pullrequest.yaml file from a code repository.
• Define parameters, workspaces, and tasks within the PipelineRun for building and deploying your application.

Key Results

• Successfully create and execute the Tekton PipelineRun using the defined .tekton/pullrequest.yaml file, enabling automated CI/CD processes for your application.

Tutorial

Create PipelineRun with Git Clone Task

Let's walk you through creating a Tekton PipelineRun using a Pipeline-as-Code approach.

1. Create a .tekton folder at the root of your repository.
2. Now add a file named pullrequest.yaml in this folder and place the below given content in it. This file will represent a PipelineRun.

  # apiVersion: tekton.dev/v1beta1
  # kind: PipelineRun
  # metadata:
  #   name: git-clone
  #   annotations:
  #     pipelinesascode.tekton.dev/on-event: "[pull_request]"
  #     pipelinesascode.tekton.dev/on-target-branch: "main"
  #     pipelinesascode.tekton.dev/task: "[git-clone]"
  #     pipelinesascode.tekton.dev/max-keep-runs: "2"

  # spec:
  #   params:
  #     - name: repo_url
  #       value: {{body.pull_request.head.repo.ssh_url}}
  #     - name: git_revision
  #       value: {{revision}}
  #   pipelineSpec:
  #     params:
  #       - name: repo_url
  #       - name: git_revision
  #     workspaces:
  #       - name: source
  #       - name: ssh-directory
  #     tasks:
  #       - name: fetch-repository
  #         taskRef:
  #           name: git-clone
  #           kind: ClusterTask
  #         workspaces:
  #           - name: output
  #             workspace: source
  #           - name: ssh-directory
  #             workspace: ssh-directory
  #         params:
  #           - name: depth
  #             value: "0"
  #           - name: url
  #             value: $(params.repo_url)
  #           - name: revision
  #             value: $(params.git_revision)

  #   workspaces:
  #     - name: source
  #       volumeClaimTemplate:
  #         spec:
  #           accessModes:
  #             - ReadWriteOnce
  #           resources:
  #             requests:
  #               storage: 1Gi
  #     - name: ssh-directory
  #       secret:
  #         secretName: nordmart-api-ssh-creds

1. Provide values for image_registry, and helm_registry parameters. You can find the urls from here. image_registry url should be succeeded by your application name. Example: nexus-docker-stakater-nexus.apps.lab.kubeapp.cloud/review-api

2. Now create a pull request on the repository with these changes. This should trigger a pipeline on your cluster.

3. You can go to your tenant's build namespace and see the pipeline running.

Exploring the Git Clone Task

The Git Clone task serves as the initial step in your pipeline, responsible for fetching the source code repository. Let's break down the key components:

1. name: fetch-repository: This names the task, making it identifiable within the pipeline.

2. Task Reference (taskRef): The Git Clone task is referred to using the name git-clone, which corresponds to a Task defined in the Tekton Catalog. This task knows how to clone a Git repository.

3. Workspaces (workspaces): The task interacts with two workspaces;output and ssh-directory. The output workspace will store the cloned repository, while the ssh-directory workspace provides SSH authentication. This means that the private key stored in the secret nordmart-ssh-creds will be utilized during the cloning process.

4. Parameters (params):

depth: Specifies the depth of the Git clone. A value of "0" indicates a full clone.

url: The URL of the source code repository. This parameter is dynamically fetched from the repo_url parameter defined in the PipelineRun.

revision: The Git revision to fetch, often corresponding to a specific branch or commit. This parameter is also dynamically fetched from the git_revision parameter in the PipelineRun.

Great! Let's add more tasks in our pipelineRun in coming tutorials.