In this guide, we will look deeper into Tekton’s Pipeline, PipelineRun, and Task definitions.

A pipeline is a set of tasks executed in a sequence to form a CI/CD workflow. The pipeline definition is strictly typed, specifying parameters, workspaces, and tasks to be executed.

Workspaces, one of the fundamental concepts in Tekton, act as shared storage for tasks within a single pipeline. They are isolated to each pipeline, thereby ensuring that the data is self-contained and secure. For our purpose, we will create three workspaces:

1. Source: This workspace serves as the location where our repositories are cloned. It allows for direct interaction with the cloned files.

2. git-credentials: This workspace hosts the git-credentials, which are generated from the SSH key we previously created. These credentials are mounted into the workspace as a Kubernetes secret.

3. git-credentials-envs: Same as before, but for the environments repository instead.

4. Dockercfg: Here, our Docker secret is mounted. This allows us to authenticate with Docker, enabling the pulling and pushing of Docker images.

PipelineRun

PipelineRun is a Tekton resource that represents an instantiation and execution of a Pipeline. It is triggered by a TriggerTemplate, which uses the input from the GitHub payload. Upon receiving an event from the EventListener, the TriggerTemplate initiates a new PipelineRun execution. The execution consists of:

• A reference pipelineRef to the corresponding Pipeline definition.
• A custom-generated name that follows the format: {reponame}-{author}-{branch-name}.
• Usage of the pipeline service account, which we previously created in the dependencies section.
• Workspaces for the git-credentials and Dockercfg.
• Another workspace, named source, requested via volumeClaimTemplate for 2GB of storage using the Longhorn storage class.
• A set of params required for the pipeline execution, such as the git head commit ID, commit message, author, and more.

It also provides a diverse set of tasks. Some of these tasks are supplied by the platform itself, while others originate from the upstream community. One such community-provided task is the git-clone task.

Git-clone

The git-clone task is designed to operate with our GitHub SSH clone URL. In combination with the git-credentials that were generated during the execution of the TaskRun create-github-resources (a step we previously discussed in the dependencies section), this task performs the vital function of cloning our GitHub repositories.

Identify

This task executes and reads the application version from the package.json and write as an task output. Outputs are readable for other tasks within the same pipeline.

Kube-linter

Uses the kube linter binary to enforce Kubernetes best practices. The current list of included patterns are: unset-memory-requirements,unset-cpu-requirements,no-extensions-v1beta,mismatching-selector,writable-host-mount

Npm-install

This is uses the Red Hat Ubi8 Node.js v16 image and has several steps:

1. Set the proxy registry to cache packages using our local instance of Verdaccio
2. Install the dependencies using Verdaccio as a proxy
3. Run the unit tests including code coverage

Image build (branch)

This is a task that will be executed only if the branch is not main.

Image build (main)

This is a task that will be executed only if the branch is main.

This task uses the git-credentials-envs secret. This secret is generated together during the taskrun github-create-resources. We send the private key to the key storage in github and store the private key in the secret.

This task has several steps:

1. Bump the version: Here we clone the repository and replace the Chart.yaml version with the one from the source code. The Chart.yaml needs to be updated if some changes occur in the chart folder and will need to be deployed. Also, we update the application version, which represents the source code version. From the environments repository, which contains the live and running application, we clone, and then replace some fields with the desired version, from the current source code.

If the chart version is not bumped, it will replace the current chart in the chart museum and you will need to hard refresh in argocd to be able to see the new chart application reflected.

Deploy