Chapter 4: Stepping into Tasks

In the previous chapter, you prepared your local environment to build, manage, and run Tekton CI/CD pipelines. It is now time to get started with some hands-on examples. First, we will recap the concepts of Tasks from Chapter 2, A Cloud-Native Approach to CI/CD, and we will see where they fit in the context of Tekton Pipelines. We will then look at how to build your tasks. Getting a good understanding of the basic principles is key to mastering larger and more complex pipelines.

Once those have been covered, we will jump into some practical use cases. Starting with the most basic task possible, we will build on it to create something that can be used in your day-to-day life as a software developer. Once tasks have been executed, it will be possible to explore task runs and see those tasks' output. Apart from looking at the raw output, we will also explore ways to view that output with some of the tools you installed in the previous chapter....

Technical requirements

You can find all of the examples described in this chapter in the chapter-4 folder of the Git repository: https://github.com/PacktPublishing/Building-CI-CD-systems-using-Tekton.

Check out the following link to see the Code in Action video: https://bit.ly/3BKJxXM

Introducing tasks

The first Tekton concept to which you will be introduced here is a task. Tasks are the basic building block that you will use to build your larger pipelines.

In a nutshell, tasks should perform a single operation in your CI/CD pipeline. Examples of tasks could include cloning a repository, compiling some code, or running a series of tests. Those tasks can take multiple forms and can be more or less complex, depending on your needs. When building your own, you should also try to make them as reusable as possible.

Tasks are defined with YAML files that describe what you want to achieve. The definition of a task follows the standard for all Kubernetes objects. You will specify the API version to use and the kind of object you are defining. Then add some metadata to identify the task.

As a rule of thumb, your tasks will always start like this:

apiVersion: tekton.dev/v1beta1 
kind: Task 
 metadata:   
   name: example-task-name 
&...

Understanding Steps

Steps are the only required objects to create a task, and that makes sense. Steps describe the containers that will run as part of the task. This is where the actual operations to be performed on your inputs happen.

In the YAML file that describes the task, you define steps by adding an array describing the steps and the order they should be performed in.

Each step must have, at a minimum, an image to use. It is also highly recommended to use a command value or a script field. This is because the container's entry point is overwritten with an executable that manages the step execution for Tekton.

A typical Step would also contain a name and would generally look like this:

spec: 
  steps: 
    - image: alpine:3.12 
      command:  
        - /bin/bash 
        - -c 
     ...

Building your first task

In this section, you will create your first Hello World task. While this task might not be instrumental in your day-to-day life, it will demonstrate the basic concepts to build your first Tekton task:

1. First, start with a new YAML file called hello.yaml. In that file, start by specifying the API version to use and the kind of object described:

   apiVersion: tekton.dev/v1beta1
   kind: Task

2. Next, add in some metadata. For this first example, we will stick with the bare minimum and only add a task name:

   metadata: 
     name: hello 

3. Now that you've described the task and named it, you can add a spec for it. Here, it will contain a single step:

   spec: 
     steps: 

   For this single step, you will use the Universal Base Images UBI image to run a Bash script.

   About the UBI

   Red Hat UBI offers a lightweight version of Red Hat Enterprise Linux as a base image to build your containers. It offers great reliability and high security for your containers...

Adding task parameters

One of the goals that you should aim for when building your tasks is to make them as reusable as possible. A simple way to reuse a task in different contexts is to add parameters to them. You can then substitute the values of those parameters in the steps that compose your task.

Making the Hello task more reusable

For this first example, you can create a new file called hello-param.yaml in which you will copy the content of the existing hello.yaml file.

The goal is now to make this task reusable in different contexts. Instead of simply always outputting Hello World, we now want it to say hello to anyone, not just the world.

Parameters are added in the spec section of the task. This new params field will contain a list of parameters. For each parameter, you will add a name and a type. The type can be either string or array.

In this case, there will be a single parameter named who, and it will be of type string:

  params: 
 ...

Sharing data

Because all the steps in a task are actually containers running in a single Pod, it is possible to share volumes across those containers. In fact, tasks already do that for you. There are various ways to use this volume, or you could mount your own from an existing PersistentVolumeClaim.

Accessing the home directory

Deprecation notice

As documented in pull request #3878 (https://github.com/tektoncd/pipeline/pull/3878), this feature has been deprecated as of version 0.24. If you are using version 0.20.1 as specified in Chapter 3, Installation and Getting Started, it might work, but there are no guarantees that it won't break when using a more recent version of Tekton.

An easy way to share information across your steps is to use the home directory directly. When tasks are initiated, the task run will mount a volume named /tekton/home in each container that runs a step. Accessing this folder is simply a matter of changing the directory to ~.

To see how...

Visualizing tasks

So far, you've used the tkn CLI tool to visualize the tasks that you have added to your cluster, but that is not the only way. If you've installed the Visual Studio Code (VS Code) extension and Tekton Dashboard, you can find more information about your tasks there.

The VS Code Tekton Pipelines extension

If you installed the Tekton Pipelines VS Code extension in Chapter 3, Installation and Getting Started, then you have access to the Tekton pipelines panel directly from your IDE. If you select the Tekton pipelines in the navigation bar, it should open up a panel that describes everything related to Tekton that you have on this cluster.

You can see that panel in the following screenshot:

Figure 4.1 – The Tekton Pipelines panel in VS Code

From this view, you can see the list of tasks that you've created already. If you click on one of them, you will also see all the associated task runs and their state...

Digging into TaskRuns

Task runs are the actual executions of the tasks themselves. Tasks are essentially just a template to build task runs. When you use the tkn CLI tool to start a task, it uses that template, binds the parameters and the options, and then starts the execution.

The visualization tools, such as the VS Code extension or Tekton Dashboard, can help get some insights about the task runs, but sometimes, you might need more information.

To see the content of a task run, start by creating one for the groceries Task that you created earlier:

$ tkn task start groceries --showlog 
? Value for param `grocery-items` of type `array`? milk,bread,coffee 
TaskRun started: groceries-run-k24zp 
Waiting for logs to be available... 
 
[grocery-list] Grocery List 
[grocery-list] => milk 
[grocery-list] => bread 
[grocery-list] => coffee 

Notice the line that starts with TaskRun started. It should show the name of the task run that was just started. This is a random...

Getting your hands dirty

It is time for you to test out those newly learned skills. You can find a solution to those problems in the Assessments section of this book. Those challenges will use the concepts that you have seen in this chapter.

More than Hello World

In this first challenge, build a task with three steps. The first step should output a log message stating that the task has started. Then, the task will sleep for a number of seconds that the user specifies. In the third step, the task should log a string that the user provides. Be sure to add default values to those two parameters. Now try running the task with the tkn CLI tool. Run it a second time using the default values this time. Start this task a third time, specifying the parameter values directly in the command line.

Tips

- You will have three steps and two parameters in this task.

- Use the default field to set a default value to the parameters.

- With the CLI tool, you can use the --use...

Summary

Now you know everything there is to know about tasks. Throughout this chapter, you've learned more about how tasks and Steps relate to each other. You've also seen how each task runs in a single Pod and how the steps each run in their own containers.

This chapter also showed you how to build your first tasks. You can now build a Tekton task that contains multiple steps along with a collection of parameters. For when you want to share data between those containers running in the task, you have learned about different ways to do so.

Finally, you have also seen how to debug your containers by using some visualization tools, such as the Tekton VS Code extension and Tekton Dashboard. If you need more details, you also know how to analyze the content of a task run.

Understanding how to create those basic building blocks is key to building efficient Tekton CI/CD pipelines, and now that you have this knowledge, you are ready to jump into pipelines in the next...