On This Page

The core objective of this is to generate pipelines for every service identified by the platform. This component persistently monitors the pipeline folder in each repository, applying changes instantly whenever a modification occurs. This feature enables teams to create their own pipelines that reflect immediately on the cluster, fostering an environment of rapid iteration and development. The components generated under this category include:

  • Ingresses: To expose an endpoint to receive the github webhook
  • Pipelines: A pipeline definition combining many tasks together in a sequenced way
  • Trigger Templates: These are resource templates that specify how new resources will be created in response to events.
  • Trigger Bindings: They link event payloads to input parameters of Trigger Templates.
  • EventListeners: A event-based interface that starts new pipeline runs and tasks in response to events, such as a GitHub webhook.

So let’s assume everything from the previous dependencies generator section is up and running. Since everything ran before given the service-1 is already discovered, we can inspect and see if the Pipeline for the service already exists. So let’s investigate a little. Starting with the Pipeline itself:

tkn pipeline describe service-1 -n service-1-ci-cd

And we should get the response with several sections. Let’s have a look on the params, but do not worry, all of these params will be fulfiled by the payload from GitHub.

NAME              TYPE     DESCRIPTION              DEFAULT VALUE
∙ ref             string   Ref of the applicat...   ---
∙ revision        string   git unique head com...   ---
∙ repourl         string   repository URL           ---
∙ reponame        string   repository name          ---
∙ author          string   commit author usern...   ---
∙ email           string   commit author email      ---
∙ message         string   commit message           ---
∙ truncated_sha   string   7 digits from the h...   ---
∙ revision_type   string   type of branch, mas...   ---
∙ github_org      string   github organisation      ---

To fully grasp the operation of our system, it’s essential to understand how these components interact and communicate. In this section, we’ll briefly outline the information flow across these components. For every identified service, we generate these components, ensuring that the pipeline is accessible and prepared for execution.

Please note that the pipelines generator is located in the platform repository under chart/gene/templates/pipelines.yaml file.

To understand the sequence of information flow, let’s follow the process below:

  1. The Ingress is configured to listen to the path /github/dx-book/service-1/webhook on the domain eu-north-1.training.dx-book.com, as defined in the shared.yaml provided by environments repository. All traffic coming to this path is redirected to the EventListener, named el-service-1.

  2. Whenever a new event is received via the Ingress, it is processed by the EventListener pod. This pod uses the TriggerBinding to extract payload data, such as commit messages, SHA, author, branch, and more, converting this information into parameters.

  3. The TriggerTemplate steps in next. It takes the parameters from the TriggerBinding and maps them to a resource template called PipelineRun, thereby invoking a pipelineRef.

  4. The pipelineRef from the preceding step points to the Pipeline definition. This definition includes a sequence of tasks, which when executed, run the pipeline.

To summarize, the process starts with a new Git commit entering the system via the Ingress. This commit navigates through the EventListeners, where its details are mapped using the Trigger Binding and Trigger Template. Consequently, this process triggers a new PipelineRun execution, incorporating custom parameters from the GitHub payload.

Triggering the pipeline

We should be triggering the pipeline with a new commit and it should hit a object called EventListener. Let’s learn more about the EventListener here. In our case, we’ll have two sections inside the EventListeners, called Interceptors, and we will intercept two events:

  1. Push Event: We’ll filter when the payload from Github is from a Push Event and we’ll get some data, such as body.head_commit.id and body.head_commit.author.name and provide to the PipelineRun.

  2. Delete Event: Here we filter by the Delete branch event, this is useful whenever we want to delete images or run some cleanup jobs whenever a branch is deleted. It keeps things organized.

Let’s see it in detail, run:

tkn eventlistener describe service-1 -n service-1-ci-cd

You can see the interceptor and the bindings, each of those params will be provided for the TriggerBinding, then to the TriggerTemplate, and then will trigger a PipelineRun with a combination of those inputs.

So let’s try to trigger a new PipelineRun going through all the sequence we described before. Initially, we’ll do it locally and then after using a new git commit.

1. Locally using port-forward

In the describe we found a local url http://el-service-1.service-1-ci-cd.svc.cluster.local:8080. Let’s forward the port and try a curl to the endpoint.

kubectl port-forward svc/el-service-1 -n service-1-ci-cd 8081:8080 
curl -X POST -H "Content-Type: application/json" -d '{"key1":"value1", "key2":"value2"}' http://localhost:8081

And the response should look something like this:

{"eventListener":"service-1","namespace":"service-1-ci-cd","eventListenerUID":"b23a18d8-9b11-48b5-b6d2-c2d79590718c","eventID":"b97e6bf2-baf4-40f8-9991-2666ae6497b1"}

For logs on the EventListener pod, responding to our request, we can see the error since the key values we provided are not what the EventListener was expecting, but for now is enough.

tkn eventlistener logs service-1 -n service-1-ci-cd

2. Via git commit

In your service-1 repository folder, run:

git commit --allow-empty -m "Empty commit"
git push origin main

Now let’s see the EventListener logs and make sure we got a webhook from GitHub to our EventListener and the mapping was executed and the PipelineRun was triggered.

tkn eventlistener logs service-1 -n service-1-ci-cd

Tekton Dashboard

The simplest method to visualize the execution of the PipelineRun in Tekton is through its dashboard. Here’s a brief guide on how to use it: you can execute kubectl proxy, and then access the link provided below.

Troubleshooting

Troubleshooting is more detailed in the official docs .

Learn more