Chapter 8: Adding when Expressions

In the pipelines you've built so far, Tekton executed tasks in a specified order as long as the previous one was successful. As you work your way toward more advanced CI/CD Tekton pipelines, you will encounter cases where some of your tasks will need to be guarded. A typical use case would be to prevent a deployment task from being executed if the branch on which a commit happened is anything but main.

When expressions can be added to Tekton tasks to add a condition on when to execute a specific task. In this chapter, you will learn more about building your when expressions and how to add them to a task to block their execution.

Finally, to decide whether a task should be executed or not, you will see how you can use pipeline parameters as an input to evaluate.

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

• Introducing when expressions
• Using when expressions with parameters
• Using the notin...

Technical requirements

You can find all of the examples described in this chapter in the chapter-8 folder of the Git repository: 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/3rBiQ2R

Introducing when expressions

Sometimes, you will want some tasks to happen based on certain conditions. To do this, you will need to use when expressions. You can think of them as if statements for your pipelines.

Tekton evaluates when expressions before task execution. If the described condition is met, Tekton will proceed with the task. Otherwise, the task is skipped.

When you need when expressions, you will add them as part of the task definition in a pipeline description.

They have three properties – input, operator, and values. This is what a typical when expression would look like:

   when: 
     - input: "true" 
       operator: in 
       values: ["true"] 

For input, you can use a static string or a variable substitution. Typical variables would be a pipeline parameter value or the value of a previous task result.

There are two operators...

Using when expressions with parameters

For this first example, you will build a guess-the-number type of game. When you start the pipeline, it will ask you for a number as a parameter. In the pipeline, a when expression will be used to compare this parameter's value with a hardcoded number. If the number is a match, it will output a message saying that you guessed the number accurately. The logger task that you built in Chapter 5, Jumping into Pipelines, will be used in this pipeline to output the messages. For convenience, here is the task definition:

apiVersion: tekton.dev/v1beta1 
kind: Task 
metadata: 
 name: logger 
spec: 
 params: 
   - name: text 
     type: string 
 steps: 
   - name: log 
     image: registry.access.redhat.com/ubi8/ubi-minimal 
     script: | 
       DATE=$(date +%d/%m/%Y\ %T) 
       echo [$DATE] - $(params...

Using the notin operator

In the previous example, you blocked a task execution by using a when expression. Sometimes, you might want to perform another task if a value is not matched. By using the notin operator, you can add what would be similar to an else statement. For this following example, you will add a You lose message when the number is not 3:

1. Copy over the pipeline from game.yaml into a new file called guess-notin.yaml. Change the name of this new pipeline to guess-game-notin, and keep everything else:

   apiVersion: tekton.dev/v1beta1 
   kind: Pipeline 
   metadata: 
    name: guess-game-notin 
   spec: 
    params: 
   ...
     tasks: 
      - name: win 
   … 

2. At the end of this pipeline, add a new task called lose. This task object will reference the same logger task. As a parameter, it will take You lose as the value for text:

      - name: lose 
        params: 
          - name: text 
       ...

Using when expressions with results

A common use case when dealing with pipelines is to block the execution of certain tasks based on the outcome of an earlier task. In order to achieve that, you would need to use a result. This is what you will do in this section.

First, you will create a new task that will generate a random number. Then, you will use a pipeline similar to the one you've used so far in this chapter. The decision to run the win or lose task will depend on the resulting random number from the first task:

1. In a new file called guess-result.yaml, create the following task that uses a Universal Base Image (UBI) to generate a random number and store it as a result:

   apiVersion: tekton.dev/v1beta1
   kind: Task
   metadata:
     name: random-number-generator
   spec:
     results:
       - name: random-number
         description: random number
     steps:
       - name: generate-number...

Getting your hands dirty

You can now block tasks from being executed depending on some values found in parameters or results. You are ready to test your knowledge with the following exercises. To complete the challenges, you will need to use the concepts introduced here and notions from the previous chapters.

As usual, you can find the solutions to these exercises at the end of this book, in the Assessment section.

Hello Admin

Build a pipeline that will take a username as a parameter. If the username is admin, log the text Hello Admin. For any other username, output a simple Hello message.

Tips

- This exercise is similar to the example you just did.

- Use the logger task to output messages.

- You will need two tasks, each with a different when expression.

Critical Hit

In role-playing games using dice, rolling a 20 on a 20-sided die is sometimes referred to as rolling a critical hit. For this exercise, build a pipeline that would log Critical Hit...

Summary

In this chapter, you've seen how to use conditional statements in your pipelines. You saw how you could use a parameter to block a task if needed. You can also use a result from a previous task to do the same thing.

You now have all the necessary components to build very powerful flows that will make you deploy your applications faster and more reliably.

To deploy your application into a real server, you will need to provide it with some credentials. Those can't be stored in a YAML file pushed to your repository; you will need to keep them a secret. This will be addressed in the next chapter.