Chapter 6: Debugging and Cleaning Up Pipelines and Tasks

In the previous chapters, all of your pipelines ran successfully. However, when you start implementing your Tekton continuous integration/continuous deployment (CI/CD) pipelines, chances are that this won't run as smoothly. There is a fair possibility that some of the tasks will fail at times, and that is a good thing. If you have a task running unit tests on your code base, you will want it to fail and stop the pipeline so that a broken version of your application is not deployed in production.

In this chapter, you will see what happens when a task in a pipeline fails. You will also learn a few techniques to investigate those failures. And finally, you will learn about... finally, a new concept that can be used as part of your pipelines to clean up your environment to get ready for the next run.

In this chapter, we are going to cover the following main topics:

• Debugging pipelines
• Running a halting...

Technical requirements

You can find all of the examples described in this chapter in the chapter-6 folder of the GitHub repository, found at https://github.com/PacktPublishing/Building-CI-CD-systems-using-Tekton.

You can also see the Code in Action videos at the following link: https://bit.ly/3eWxaOo

Debugging pipelines

As you build your first pipelines, you will inevitably encounter some issues. Writing pipeline definitions without getting a failing pod is just as likely as writing a piece of software without running into a bug, yet there are ways to figure out what is happening inside those pods and potentially identify issues that are causing the pipeline to break.

Let's start by creating a first task that will intentionally fail. This task will have a non-existing base image for one of the steps, and you will see how you can debug this issue when the pipeline stalls:

1. In a file named invalid-image-task.yaml, add a new task called invalid-image:

   apiVersion: tekton.dev/v1beta1 
   kind: Task 
   metadata: 
     name: invalid-image 
   spec: 
     steps: 

2. Add a single step called log, which will use an invalid image name:

      - name: log 
        image: invaliduser/nonexistingimage 

3. To be compliant with the task definition...

Running a halting task

Your pipelines are there to help you automate the delivery mechanisms of your applications. The ultimate goal is to make it possible to ship faster and more frequently. On the other hand, you also want to avoid pushing code that is broken or that doesn't pass your standards. This is why you will sometimes have some pipeline runs that won't complete. If you have a task running some failing unit tests, Tekton should not start the deployment task.

To demonstrate this, you will create a task that logs some text and then uses a specific exit code to tell Tekton whether the task succeeded or not.

Note

Normally, the executable running inside a step would provide the exit code. For those codes, 0 indicates success, while any other number indicates some failure.

You will then build a pipeline using that task to simulate failing tasks inside a CI/CD pipeline:

1. Create a new file named log-and-exit.yaml in which you create a new task called...

Adding a finally task

So far, all the pipelines that you built did not persist any data. Once the pods were terminated everything was taken down with them, and the next run always started from a fresh environment.

This won't always be the case. Most of the time, you will clone a code repository and store it on a PersistentVolumeClaim (PVC) for all tasks to access it. This exact scenario will be introduced in Chapter 7, Sharing Data with Workspaces. When you start using workspaces, you will need to clean up your persisted data to start with a clean environment each time. This is where finally tasks will come into play.

Those tasks will always be executed, even after there was a task that failed in the pipeline. Let's demonstrate this:

1. Create a new file called cleanup.yaml and create a task called cleanup:

   apiVersion: tekton.dev/v1beta1 
   kind: Task 
   metadata: 
     name: cleanup 
   spec: 

2. This task has a single step named clean. It uses a UBI to execute...

Getting your hands dirty

Now that you know everything there is to know about debugging pipelines and the finally object, you are ready to tackle these exercises. These two exercises focus on knowledge you have gained in this chapter.

You will find a solution to these exercises in the Assessments section at the end of the book.

Fail if root

Create a pipeline with a simple task. This task will check if it is running as the root user. If the container is indeed running as the root user, the task will fail.

Tips

- The UBI runs as root.

- You will need some Bash scripting in your task to validate if $(whoami) is root.

- Use the exit command to indicate that the task succeeded or failed.

Make your bets

Imagine a game of Blackjack. The current hand value is 17. Draw a random card with a value between 1 and 10 and add it to the current hand. The value should be passed to the second task as a result. If the value is 21 or less, you win, and the task should...

Summary

When you start writing your first tasks and pipelines, you can expect them to fail at times. This might be expected, but sometimes it won't be. In this chapter, you've learned all the necessary tools to find out what is going on and how you can fix those issues.

You have also seen that a task failure can be a good thing, preventing you from accidentally deploying a broken version of your application. You have also learned how to find what caused those failures.

Finally, you've seen how to run a final task to clean up your work once the pipeline execution is completed. While this hasn't been very useful so far, you will need to use this concept when you start using workspaces. These will be introduced in the next chapter.