Chapter 11: Triggering Tekton

Now that you know how Tekton Triggers can help you automate your CI/CD pipelines, it is time to put this knowledge to good use. Adding a trigger to start your pipelines automatically is the last step to build a truly automated deployment of your applications.

In this chapter, you will start by creating a simple pipeline. The goal of this pipeline will be to demonstrate that the pipeline can be triggered when you push a new commit to your code repository. Once you have added this pipeline to your cluster, you will see how to create a template, binding, and event listener to listen for GitHub webhooks.

Then, you will need to configure a code repository to connect to your cluster whenever a push event happens. After that, you will be able to test everything out and see how the pipeline is triggered.

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

• Creating a pipeline to be triggered
• Creating the trigger
• Configuring...

Technical requirements

You can find all of the examples described in this chapter in the chapter-11 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/3rDOX26

Creating a pipeline to be triggered

To test out your triggers, you will first need a pipeline that can be triggered. By now, you should have a pretty good knowledge of how to build your pipelines. In this pipeline, you will use the same task as the one called logger that you built in Chapter 5, Jumping into Pipelines. Let's now create a new file called pipeline.yaml, which will contain the following task:

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.text) 

The pipeline itself will have a...

Creating the trigger

In this section, you will learn how to create your first trigger. This trigger will listen for GitHub webhooks and automatically start the pipeline you've just built.

As you now know, you will need three components to set up your triggers. The first new object you will create here is the trigger binding.

TriggerBinding

When GitHub sends a request to your cluster, you will need to extract some of the information sent to convert it to a parameter used by the trigger template.

Webhook payloads

As you build more complex pipelines, you might want to extract more information from the webhook than just the repository name. You might want to check the branch on which the push was done or the name of the committer. You can find the full definition of the webhook payloads on the GitHub documentation site at https://docs.github.com/en/developers/webhooks-and-events/webhook-events-and-payloads#push.

In a new file named binding.yaml, start by...

Configuring the incoming webhooks

Now that you have the necessary YAML files to create your trigger, you will need a few more configurations to ensure that your cluster is listening. First, you will need to create a secret to be used to validate that the incoming requests. Then, you will need to expose a route so it can be reached from outside of the cluster. You will need the help of ngrok here to make sure that it is also available from the public internet, which you installed in Chapter 10, Getting Started with Triggers. Finally, you will need to add a webhook to a GitHub repository. This webhook will connect to your newly created trigger.

Creating a secret

To ensure that your pipeline is not launched every time a robot accidentally hits your trigger URL, you will need to create a secret. You could use any arbitrary string as a key, but it is a good practice to use a random key for each one of your triggers. For this reason, we will be using a random number converted...

Triggering the pipeline

It's finally time to test out the automation you've put in place. Ensure that you have a clone of your Git repository available on your local machine. From the folder in which the code resides, add a new file:

$ touch newfile.txt 

Now add this file to Git, commit this change, and push the changes to the code repository:

$ git add . 
$ git commit -am "New file added" 
[main b4c1143] New file added 
1 file changed, 0 insertions(+), 0 deletions(-) 
create mode 100644 newfile.txt 
$ git push origin main 
Enumerating objects: 4, done. 
Counting objects: 100% (4/4), done. 
Delta compression using up to 8 threads 
Compressing objects: 100% (2/2), done. 
Writing objects: 100% (3/3), 280 bytes | 280.00 KiB/s, done. 
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 
To github.com:joellord/tekton-book-example.git 
  6dceaf5..b4c1143 main -> main 

Now take a look at the list of pipeline runs that have been created so far...

Summary

In this chapter, you've learned how to build and configure your triggers. Using those newly created triggers, you can automate your CI/CD process even more.

You are now more familiar with the structure and usage of trigger templates, trigger bindings, and event listeners. You can use combinations of these objects to customize your triggers in your infrastructure.

You've also seen how you can expose a route from your local system so that you can test out those webhooks that GitHub emits. In a production environment, you will want to use ingresses to expose those services to the outside world.

Finally, you made some changes to your repository and were able to see that those changes automatically triggered a pipeline run. That pipeline run had access to some properties from the push event, and in your case, you were able to see the URL of the repository on which the push happened.

You now have everything needed to automate your CI/CD processes. In...