CI on Gitlab. Bringing Gitlab, Tekton and Prow together (with some magic)
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Manhart, Rafał
Many organizations are using Gitlab as a code repository and wondering too late how to establish CI pipelines. ChatOps, automatic merging, cloud-native, webhook event triggers, serverless, job reusability, scalability, bot-users, simplicity are often on the wishlist. In this showcase we will fulfill the above wishlist with open source tools, speak about the issues that we overcame and demonstrate how to use Gitlab as a pure code repository.
 Hi, Fostem. In this video, I would like to show you how to do CI on GitLab. Maybe not necessarily using the GitLab tools, but using cooler tools like Tecton or Pro. So my name is Rafa Manhard. I work as a consultant in IT, mainly in Kubernetes and Clouds. I went by bicycle to Monte Carlo last year and did a mountaineering certification, which was pretty rough and I'm very proud of. Last year, I joined a new team and my first task was to make a proof-of-concept for a cool, very sophisticated CI system. They asked what technologies we are using already and they said GitLab. Of course, GitLab has its own CI system and probably some of you know the.GitLab-CI emails that you have to include in every repo. But I wanted to use something new. The first thing I did, I was looking for cool CI solutions and most of them had CI bots. I made a list of all of the bots. There's a lot of them and probably I haven't found all of them. After days of trying the bots out and making evaluations, I found out that Pro is that bot that I would like to use in the future. What is Pro? Pro is coming from the Kubernetes GitLab project and is used on GitHub. And Pro is a chatbot that allows the user to interact with merge requests. So whenever I push something into the repo, the bots ask me to assign someone to a pull request and there's a whole structure how a pull request should be handled. So let's take a look and let's see how Pro looks like on Kubernetes project on GitHub. How to find Pro? Just Google for Kubernetes. GitHub. You can go to the official repository of Kubernetes. Just on the top, you can see there's a pull request and it was issued by a chatbot called Ked SCI Robot. That's Pro. So when you go to all the pull requests, you can see labels and let's just pick some pull request. And you can see the first comment to the pull request was issued by the CI robot. Some nice instructions, you have to assign someone. You can see the labels assigned to the pull request. That's Pro behind. Let's take a look at another pull request. Oh, yeah. Oh, and that's super nice. Here you can see that Pro ran some tests. So with this instruction, you can rerun the test, see the results of the tests. And all of this is made by the CI bot. You can see it has proof for that CI bot is called Pro. I was super happy with Pro and I was excited that they're going to use it in the future on GitLab. And I even found this map how to interact with push requests, who has to approve push requests and which parts of Pro interact with the users. And then I was looking how to use Pro on GitLab. It was not possible. I even asked the maintainers of Pro if there is a roadmap for using Pro on GitLab. And of course, they said they're looking for contributors. So if any of you want to bring Pro on GitLab, feel free to join them. Well, then I thought there's no way. I cannot use any Pro. I came back to the list of my bots and continued to search for an other alternative. But then I stumbled over Lighthouse. So what is Lighthouse? Lighthouse is also a chatbot, but it's coming from Jenkins X. Jenkins X managed to use Pro with his own solutions. And the solution is called Lighthouse. It doesn't have even a logo. And how Lighthouse works, it consists of few pods that managed incoming webhooks. For instance, Lighthouse webhooks pod, it converts the incoming webhooks from the Git provider and transfers them into Lighthouse jobs. You have a tecton controller which watches over the Lighthouse jobs and translates them into tecton pipelines. You have Focorn. And Focorn is blocking your Git provider from doing the next steps and is somehow, I would say, emulating the pipeline in your Git provider. So you see a job which is still running and you cannot proceed further. For instance, you cannot merge. There is Lighthouse Keeper. Lighthouse Keeper just watches in the chat of the pull request and is waiting for the approve label. You can specify which label it should be, but by default, it's the approve label. And of course, you have one component which is called GEC jobs and is a garbage collector for pipeline grants. So that's Lighthouse. How Lighthouse looks like, we're going to see now in the hands-on. Okay. Okay. Let's take a look at Lighthouse pods. We see a lot of pods running here. And those are the mentioned components. So you can see the webhooks, pod, the tecton controller, Keeper and the Focorn. So let's look at the logs of all of them. I'm just going to skip the logs higher. So we're going to see the fresh logs coming in. One for incoming webhooks and one for the tecton controller, which triggers the pipelines. Okay. You can already see there are some logs coming in, in one of the pods. Let's switch back. Okay. You can see in the same namespace, you can find two config maps, config and plugins. And those are specified here in the installation folder of Lighthouse. So what's inside? The config is basically the config of Lighthouse. And you have to name the verbosity or the repos you are using. And the plugins, you have to, you can configure all the plugins you are using. And you can specify which plugins are used in which repo. So for instance, if you're using repo demo three, you have to say, you want to use the plugin, for instance, labor. So for each repo, you have to specify the plugins. How to set up Lighthouse. You have to go to GitHub, there are repository. And you can see one of the webhooks is pointing on Lighthouse, on the Lighthouse hook. So whatever happens in the repository is being sent to Lighthouse. Okay. So let's see how it works. We're going to open a merge request. We're going to pick one test branch, which is a little bit different than the master branch. And we're going to open the merge request. We're going to do everything default. And now we're going to open the logs. So you can see that the webhook is going to arrive in Lighthouse. And you can see the bots are logging. And here you can see the Lighthouse bot. I called him bottom is already commenting. He's welcoming me. He's labeling the public request or merge request and also saying how to assign users. So for instance, I'm going to be assigned by myself. As you can see, there's a prefix LH, which stands for Lighthouse. And as you can see, I assigned myself the comment and then the bot Lighthouse here assigned me to the merge request. You can do other stuff. You can even use LH bark. And you're going to get some funny photos here. This one of the plugins is posting a picture of a dog. And there you go. And in the next step, you can specify pipelines, which are going to be run by the bot. But oh, and you can see here, the fochorn, the component of Lighthouse is running a pipeline. And this pipeline runs as long. There is no approved label on the public request. So if there's no one puts the approved label, the pipeline is going to be run by fochorn. And then you cannot merge to the master branch. Okay. So far, so good. We have a chatbot which works really nicely with GitLab. It's kind of pro but called Lighthouse. Yeah, but I haven't showed you the pipelines. Why? Because it's a lot of difficulties to get the pipelines running. I was communicating one of the maintainers of Lighthouse, which is Jason. And Jason said Lighthouse works really nicely but with Jenkins X. And I was not using Jenkins X. I just wanted to use Tecton. And it was not working. So after a few days of debugging, I found out that the hand chart that I was using to install Lighthouse and the Tecton pipelines was not right. There was some bug and the bug was fixed and afterwards the pipelines were working. And I also found out that the payload which is sent to the webhooks, to the pod webhooks, is not transmitted to the pipelines. So the pipelines doesn't know which reputable clone to use. It's a huge downside of Lighthouse. And I need to set up each pipeline for each repo. And I didn't want it to do that. One more downside of Lighthouse is that you have these two config maps, config and plugins, YAMLs, that you need to configure to use a specific rep or whatever you add and a new repository. So you need to set up a config, YAML and plugins. That's not very agile in my opinion. Anyhow, besides these pipelines difficulties, I had a really nice working chat bot which acts like a row. It uses all the same plugins. And yeah, it was pretty straightforward to install it with a hand chart. So I have a chat bot, I have no pipelines. So I went on and I was looking like what if there are some nice CI pipeline systems and I went through a few of them. And I saw that Lighthouse often use with Tecton. So I tried to use Tecton with Lighthouse but not the way it's intended to use. So I really wanted to get Jason payload from the webhooks into Tecton. So Tecton was the engine for the pipelines again. So why Tecton is so cool? Because it has a serverless execution. Of course there's a controller bot but the execution is serverless. It has an IS API. Containers are the building blocks and you have reusable components. So you have tasks, pipelines, pipelines, resources. All of this you can find in a Tecton hub or you can specify your own components and use them in many biplans. Tecton is supported by a few big companies who will go out and think OpenShift is using Tecton. That's why Redhead and IBM. And let's take a look at Tecton. First let's install Tecton on our cluster. We're running the cluster in GCP and I'm using a few YAML files inside Tecton. First we install the Tecton pipelines. You can see it's a few customer resources, config maps, all but you can find it on the Tecton GitHub repo. And you can already see we have two pods. One is the controller for the pipelines and the other is the webhook for the pipelines. Okay, we go on. We're just going to install the dashboard so we can see something what pipelines look like. That's also from the Git repository of Tecton and there's a pod of the dashboard. Okay. And we need to install the ingress. We need to ingress so we can see the dashboard on our cluster. So that's all. Now we install Tecton. Okay, nice. Now we installed Tecton. But how does it work? So Tecton consists of a few customer resources and the basic building block is a task. It consists of many steps and each step is a container and a step can do stuff like create a deer in a repository, a clone repository. Very simple task. The task is bundled in a pipeline. It can be triggered by a pipeline run. So whenever I deploy a pipeline run, the pipeline is triggered and the pipeline triggers the task in a specific order. You can define the order which task should be triggered after which task. So let's have a look. Since we already installed Tecton, let's have a look how it looks like. Okay. A very simple demo. We have a task which is only doing echo and it will show the message. And we have a task run which triggers the task to run. Let's take a look how it looks like. We have our three Tecton pods. We take a look here to watch the task runs. And we're going to apply those two resources. First, let's deploy the task. So we have a task in the cluster waiting for the task run to trigger the task. And now we're going to deploy it. Let's take a look here. And we see the task run. It's impending. We are using a new pod which is starting. And it took 11 seconds. Let's take a look at the logs. Hello, CUNP dudes. You are successful. You can see it here. That's how the basic building blocks of Tecton works. Task is triggered by task run. Okay. Let's continue. We saw a task in the task run. Let's take a look at some one step further which is a pipeline and a pipeline run. So in the task demo, we have a few tasks. Two of them. We have a pipeline that is referencing those two tasks. And we have a pipeline run which triggers the pipeline. So similarly as before, let's take a look. Task runs, pipeline runs, now none. We have still our three pods. So let's go on and let's deploy all the resources that we need. Once we are going to deploy the tasks. This one, you have these two tasks. Okay. In the cluster. Let's continue the pipeline which is referencing the tasks. Yup. Pipeline in the cluster. And now the last one is going to trigger pipeline run and task runs. As you can see. We have a task run and pipeline run. We have two new pods. One is completed. The next one is starting. You can see it consists of two containers. Yeah. And let's take a look at the logs. Maybe let's take a simple one. Hello. You see the message. Let's take a look at the other one. Yeah. It shows us the information about the pipeline. It's the parameters that you get from the higher resources into the pipeline. And everything was successful. So that's how it is. Very simple. Tecton pipelines. Very cool feature of Tecton pipeline resources. Piping resources allow you to predefine resources that you very often use in pipelines. I'm using the most the Git resource and image resource. I can define from which repository to clone a repository down or where to push it, where to push the image that was built during the CI. There are many more resources. You have a pool request resource. You have storage resource, a cluster resource, and clothe event resource. And there are many more coming. We have our pipelines. So let's set up our repository and create a web hook to trigger our pipelines. So in GitLab, we just go to web hooks. We create a web hook which is reacting on push events. That's the only thing you need to do to trigger pipelines from GitLab. Now we have the web hook installed in GitLab. It's going to trigger our pipeline. We have a web hook pointing onto our ingress, but there's nothing behind. So that's why we have to use Tecton triggers. It's another part of Tecton. You can find in the same repository on Git. And Tecton triggers is the building block between the pipelines and our Git provider. First, let's install it. Okay. Let's go back to our cluster. And there we go. We have a YAML which installs the triggers. You can get it from the Git repository of Tecton triggers. Nope, typo. Just let's apply. Oh, I guess there's typo. One more time. Okay. Let's install the triggers. Here you can find in the Git repository where Tecton is. It's the other part of Tecton. Okay. Let's apply the YAML. Wow, it's a long one. And you can see the pods. We are getting two new pods. The triggers controller and the triggers web hook. Our Git web hook is going to point onto the web hook pod of triggers. Okay. We installed another thing, another part of Tecton, the Tecton triggers. But what is Tecton triggers exactly? Let's have a look. Tecton triggers, it's the connecting block between the web hook and the pipeline. You can see here, your Git provider, here's GitHub, but we are using GitLab, is sending a web hook. The web hook is being received by the event listener. The event listener can decide, depending on the payload of the web hook, where to send it to which trigger binding. The trigger binding is sending it to the trigger template. The trigger template has a pipeline run, which triggers a pipeline, and the pipeline triggers the tasks. May sound very complex, but it makes everything much more granular, and you can exchange all the building blocks, and it works really fine. So let's have a look. Let's have a hands-on. Let's go back to our environment, and here you can see the listener, and it's listening to event type push hook, whatever we push something to our GitLab provider. It's going to send a push web hook. That's how the web hook looks like. It's a JSON. It has a lot of information about our Git repository. It says it's a push hook. The listener is going to only let the push hooks through, and let's deploy the whole thing. The listener, the trigger bindings, the triggers, and let's see. We're going to look at the locks of the event listener. Let's put enter, so we're going to see the new locks coming. We'll try to use a curl, and we're going to send with a curl the JSON payload to our ingress and to our event listener, and we will try to trigger the pipeline by this curl. And you can see something arrived at our event listener. We have a new pod, a new pipeline run, and a new task run. And everything was successful. Let's take a look. We're completed pod, and you can see here the pod consists of two containers. That means a task consists of two steps. Let's pick one of them. Let's for instance look at our step run, which is showing us whatever is into the repository, and you can see that's our repository. Those are the files from our repository. That's a simple example of how triggers work. You can see how triggers work. Let's take a look on the sequence, how the JSON payload arrives in a container. You can see here with a red arrow, it's a straight line, but to get from a payload to the task, you need to go over a trigger binding. The trigger binding takes the payload over the value to the trigger template. The trigger template takes the value to the pipeline definition. And the pipeline definition puts the value into the task. The task is a pod with a few steps, one of the steps of the container, and to get information there. For instance, you want to clone a Git repository in the task, and you need to know the name and the commit ID of the Git repository. And that's how the information is going from the payload into the task. And actually, this is the ingredient that we are missing in Lighthouse. That's why you couldn't use Lighthouse, because in Lighthouse, when using Tec-Ton pipelines and not using Jenkins X, you cannot get the information from the JSON body into the task. But with Tec-Ton triggers and Tec-Ton, we can trigger pipelines from our Git provider, regardless of the Git provider. It can be GitHub, GitLab, and others. And we can use it next to Pro and Lighthouse. Okay. So we have a chat pod. We have really cool Tec-Ton pipelines. It looks like we have everything, but there's something missing. We are missing a little bit magic. And what is the magic? Magic is Kevin. Who is Kevin? Kevin is one of the Tec-Ton lead contributors. And Kevin helped me a lot, because I was missing one thing in my pipelines and my CI. I couldn't see the pipelines running in GitLab. So I was pushing something into GitLab. And I couldn't see in the GUI any information about the pipeline. I didn't know if the pipeline was successful or not. I only saw the task runs and pipeline runs, which were saying they are successful or they failed, but I haven't seen it in the GUI. So I was researching, and Kevin helped me a lot. In Tec-Ton, in the Git repository of Tec-Ton, you have one part which is called experimental. And there Kevin showed me a very cool thing, which is the commit status tracker. What is the commit status tracker? It's another controller. Basically, it's just a Docker container running. And it watches pipeline runs, and then it goes to annotations, and it looks at the annotations. You have to have specific annotations, like a Git status, status context, status description. And depending on your annotations, the commit status tracker is going to report back to GitHub or GitLab, and it's going to show you a pipeline running in your Git provider. And as long as the pipeline is not green, you cannot merge your pull request, for instance. It was the missing block to have a really cool CI system. Yeah, let's install it. We back again to our environment. Before we go into the commit status tracker, as you can see, we have already a few ports running. So there is our YAML. And here you can see the commit status tracker Docker image. And it's very simple. Let's apply all of this. And you can see the four seconds our commit status tracker is running. And let's try some example. I'm going to deploy something with specific annotations. And the commit status tracker is going to look on pipeline runs with those annotations. You can see there's a status context, even a website that you can refer. That means when I'm on the pipeline, I'm going to click on the pipeline in GitLab, and I'm going to land on this page. And here you can see a pipeline resource, Git, that needs two things, revision, and the link to the repository. Let's have a look. Okay, in our GitLab, under pipelines, there's nothing. It's clean. Let's switch now to our tests. We can apply. We have a task pipeline and pipeline run. Let's apply the whole deal. And we couldn't get the pipeline. Oh, yeah. That's because we deployed the pipeline run before the pipeline was deployed. Is it one more time? Now, step by step, we delete the pipeline run. We apply the task. Okay, task is in the cluster. Then we go with the pipeline. So, we can cluster now, we can trigger the pipeline run. Oops, one more time task. Let's go with pipeline run. Okay, we are triggering the pipeline run. It's pending. Oh, it's already success. We have a new pot. We have results. And let's look at our Git repository. And we have a pipeline which is already green because the pipeline passed is green. And that's because of our commit to the structure. Nice. We have all the building blocks. I think we have done now with hands-on. And you can see now, we have an emerging bot, or chat bot, which is Pro using Jenkins X Lighthouse. We have a tecton for running our pipelines. And we have a little bit of Kevin magic. The commit structure to report the results of the pipeline's back to our Git provider. Git provider. Let's have a look. There's this diagram which is comparing Pro and tecton. So in Pro, you have a plugin called hook, which is waiting for the web hooks. In tecton, we have tecton triggers with interceptors, even listeners, as we saw before. For job execution in Pro, you have a plank. But in tecton, you have pipelines. Tecton pipelines. In Pro, you have a dashboard, deck. It's missing in Lighthouse because Lighthouse is not having all the plugins of Pro. But we can use our tecton dashboard that we installed in our hands-on. In Pro, we have tight for merging in tecton. There is no tight. There is no bot. What we are using Lighthouse, which is Pro. And that's how we are having a nice merging bot. I think the nicest available. For the big jobs, I haven't seen this, but for this, we can use triggers and Kubernetes Chrome jobs. Trigger can trigger a task, which have a Chrome job and a periodic job. And for garbage collection, where we don't have anything for garbage collection, but for this, you can use a simple Chrome job. You don't need to use anything technology. Okay. So I believe that with these three steps, we managed to build up a really nice CI system on top of GitLab. We are not using GitLab as an app of all the apps. We want to use GitLab as a Git repository, not as an engine for running pipelines. With GitLab, we could use GitPocket or GitHub, as long as we are using Lighthouse, tecton, and our small magic step. We believe in the future, tecton is going to manage to create some better technologies and to report the status of the pipelines back to the Git provider. So in the future, we are not going to need any commit status tracker. So then we just rely on our merging bot and our pipeline engine. And in the far future, when you follow the select channel of tecton and how things go, maybe we're not going to need a merging bot. We can do, maybe in the future, we're going to have only tecton. And tecton is going to do the role of a chatbot. You could do it right now, you could use the pipeline resource called puller request. And the pipeline resource could be modified depending on the comments in the chat. There's something more. There are a lot of them. The whole tecton environment is much, much bigger. We have cell interceptors so we can modify the JSON body incoming to the webhooks. We have conditions. We have a lot of experimental features like our commit status tracker. There are more. And I saw there's even a tecton result server which is going to keep our results of our pipeline guns. And even so, someone is working on a notifier. There's also a tecton controller which keeps our tecton running but unfortunately it only works with old tecton versions. I guess the tecton people need more support. And there's a tecton hub. And from the tecton hub you can get tasks and tecton pipelines and you can even contribute there. Okay, that's how our tecton setup on GitLab is working. I believe it's a much nicer setup of GitLab than using this GitLab CI. Yeah, that's it. Thank yougem for the time. The famine of death You are you there? Perfect. Okay, I'm live. And I can hear myself. So who's that the speaker of those not here yet. He might join in a second, maybe a month or it or young you could ping in. And then we'll get to the questions. I'll start with first question. I believe. For some reason, the question is, I'm a pollinger. I asked that he's not sure if he if he missed the pardon beginning but why Rafa is using an external CI solution and not the Github CI. I think the explanation Rafa gave in the end that the goal was basically to use the Github CI to the bear tool that the CI runner so to say. Rafa, there you are. I was in the wrong room. Yeah, why are we using the other technologies not get that CI. First of all, I wanted to use pro and there was no solution for problem get lab. That's why I went with light house and then from light house I came to tecton. The other reason was, I didn't want to be locked in and get lab. So I want to be able to easily switch to get help order. There were also other reasons I was working before with get lab and we use get laps. He eyes a lot. And it was not scaling nicely because then you had the include of a pipeline which was including another pipeline at the end. No one knew where one pipeline was in. Yeah. Also from my experience, it was not scaling well enough. So sometimes pipeline were not starting and there were some issues. And with tecton I have all the pipelines represented as Kubernetes object. I mean, you just look on your Kubernetes cluster and there's your pipeline. You don't have to go into your repository. So that were the main reasons and my private reason was.
 Hi, Fostem.  In this video, I would like to show you how to do CI on GitLab.  Maybe not necessarily using the GitLab tools, but using cooler tools like Tecton or Pro.  So my name is Rafa Manhard.  I work as a consultant in IT, mainly in Kubernetes and Clouds.  I went by bicycle to Monte Carlo last year and did a mountaineering certification, which  was pretty rough and I'm very proud of.  Last year, I joined a new team and my first task was to make a proof-of-concept for a  cool, very sophisticated CI system.  They asked what technologies we are using already and they said GitLab.  Of course, GitLab has its own CI system and probably some of you know the.GitLab-CI  emails that you have to include in every repo.  But I wanted to use something new.  The first thing I did, I was looking for cool CI solutions and most of them had CI bots.  I made a list of all of the bots.  There's a lot of them and probably I haven't found all of them.  After days of trying the bots out and making evaluations, I found out that Pro is that bot  that I would like to use in the future.  What is Pro?  Pro is coming from the Kubernetes GitLab project and is used on GitHub.  And Pro is a chatbot that allows the user to interact with merge requests.  So whenever I push something into the repo, the bots ask me to assign someone to a pull  request and there's a whole structure how a pull request should be handled.  So let's take a look and let's see how Pro looks like on Kubernetes project on GitHub.  How to find Pro?  Just Google for Kubernetes.  GitHub.  You can go to the official repository of Kubernetes.  Just on the top, you can see there's a pull request and it was issued by a chatbot called  Ked SCI Robot.  That's Pro.  So when you go to all the pull requests, you can see labels and let's just pick some  pull request.  And you can see the first comment to the pull request was issued by the CI robot.  Some nice instructions, you have to assign someone.  You can see the labels assigned to the pull request.  That's Pro behind.  Let's take a look at another pull request.  Oh, yeah.  Oh, and that's super nice.  Here you can see that Pro ran some tests.  So with this instruction, you can rerun the test, see the results of the tests.  And all of this is made by the CI bot.  You can see it has proof for that CI bot is called Pro.  I was super happy with Pro and I was excited that they're going to use it in the future  on GitLab.  And I even found this map how to interact with push requests, who has to approve push  requests and which parts of Pro interact with the users.  And then I was looking how to use Pro on GitLab.  It was not possible.  I even asked the maintainers of Pro if there is a roadmap for using Pro on GitLab.  And of course, they said they're looking for contributors.  So if any of you want to bring Pro on GitLab, feel free to join them.  Well, then I thought there's no way.  I cannot use any Pro.  I came back to the list of my bots and continued to search for an other alternative.  But then I stumbled over Lighthouse.  So what is Lighthouse?  Lighthouse is also a chatbot, but it's coming from Jenkins X.  Jenkins X managed to use Pro with his own solutions.  And the solution is called Lighthouse.  It doesn't have even a logo.  And how Lighthouse works, it consists of few pods that managed incoming webhooks.  For instance, Lighthouse webhooks pod, it converts the incoming webhooks from the Git  provider and transfers them into Lighthouse jobs.  You have a tecton controller which watches over the Lighthouse jobs and translates them  into tecton pipelines.  You have Focorn.  And Focorn is blocking your Git provider from doing the next steps and is somehow, I would  say, emulating the pipeline in your Git provider.  So you see a job which is still running and you cannot proceed further.  For instance, you cannot merge.  There is Lighthouse Keeper.  Lighthouse Keeper just watches in the chat of the pull request and is waiting for the  approve label.  You can specify which label it should be, but by default, it's the approve label.  And of course, you have one component which is called GEC jobs and is a garbage collector  for pipeline grants.  So that's Lighthouse.  How Lighthouse looks like, we're going to see now in the hands-on.  Okay.  Okay.  Let's take a look at Lighthouse pods.  We see a lot of pods running here.  And those are the mentioned components.  So you can see the webhooks, pod, the tecton controller, Keeper and the Focorn.  So let's look at the logs of all of them.  I'm just going to skip the logs higher.  So we're going to see the fresh logs coming in.  One for incoming webhooks and one for the tecton controller, which triggers the pipelines.  Okay.  You can already see there are some logs coming in, in one of the pods.  Let's switch back.  Okay.  You can see in the same namespace, you can find two config maps, config and plugins.  And those are specified here in the installation folder of Lighthouse.  So what's inside?  The config is basically the config of Lighthouse.  And you have to name the verbosity or the repos you are using.  And the plugins, you have to, you can configure all the plugins you are using.  And you can specify which plugins are used in which repo.  So for instance, if you're using repo demo three, you have to say, you want to use the  plugin, for instance, labor.  So for each repo, you have to specify the plugins.  How to set up Lighthouse.  You have to go to GitHub, there are repository.  And you can see one of the webhooks is pointing on Lighthouse, on the Lighthouse hook.  So whatever happens in the repository is being sent to Lighthouse.  Okay.  So let's see how it works.  We're going to open a merge request.  We're going to pick one test branch, which is a little bit different than the master  branch.  And we're going to open the merge request.  We're going to do everything default.  And now we're going to open the logs.  So you can see that the webhook is going to arrive in Lighthouse.  And you can see the bots are logging.  And here you can see the Lighthouse bot.  I called him bottom is already commenting.  He's welcoming me.  He's labeling the public request or merge request and also saying how to assign users.  So for instance, I'm going to be assigned by myself.  As you can see, there's a prefix LH, which stands for Lighthouse.  And as you can see, I assigned myself the comment and then the bot Lighthouse here assigned  me to the merge request.  You can do other stuff.  You can even use LH bark.  And you're going to get some funny photos here.  This one of the plugins is posting a picture of a dog.  And there you go.  And in the next step, you can specify pipelines, which are going to be run by the bot.  But oh, and you can see here, the fochorn, the component of Lighthouse is running a pipeline.  And this pipeline runs as long.  There is no approved label on the public request.  So if there's no one puts the approved label, the pipeline is going to be run by fochorn.  And then you cannot merge to the master branch.  Okay.  So far, so good.  We have a chatbot which works really nicely with GitLab.  It's kind of pro but called Lighthouse.  Yeah, but I haven't showed you the pipelines.  Why?  Because it's a lot of difficulties to get the pipelines running.  I was communicating one of the maintainers of Lighthouse, which is Jason.  And Jason said Lighthouse works really nicely but with Jenkins X.  And I was not using Jenkins X.  I just wanted to use Tecton.  And it was not working.  So after a few days of debugging, I found out that the hand chart that I was using to  install Lighthouse and the Tecton pipelines was not right.  There was some bug and the bug was fixed and afterwards the pipelines were working.  And I also found out that the payload which is sent to the webhooks, to the pod webhooks,  is not transmitted to the pipelines.  So the pipelines doesn't know which reputable clone to use.  It's a huge downside of Lighthouse.  And I need to set up each pipeline for each repo.  And I didn't want it to do that.  One more downside of Lighthouse is that you have these two config maps, config and plugins,  YAMLs, that you need to configure to use a specific rep or whatever you add and a new  repository.  So you need to set up a config, YAML and plugins.  That's not very agile in my opinion.  Anyhow, besides these pipelines difficulties, I had a really nice working chat bot which  acts like a row.  It uses all the same plugins.  And yeah, it was pretty straightforward to install it with a hand chart.  So I have a chat bot, I have no pipelines.  So I went on and I was looking like what if there are some nice CI pipeline systems and  I went through a few of them.  And I saw that Lighthouse often use with Tecton.  So I tried to use Tecton with Lighthouse but not the way it's intended to use.  So I really wanted to get Jason payload from the webhooks into Tecton.  So Tecton was the engine for the pipelines again.  So why Tecton is so cool?  Because it has a serverless execution.  Of course there's a controller bot but the execution is serverless.  It has an IS API.  Containers are the building blocks and you have reusable components.  So you have tasks, pipelines, pipelines, resources.  All of this you can find in a Tecton hub or you can specify your own components and use  them in many biplans.  Tecton is supported by a few big companies who will go out and think OpenShift is using  Tecton.  That's why Redhead and IBM.  And let's take a look at Tecton.  First let's install Tecton on our cluster.  We're running the cluster in GCP and I'm using a few YAML files inside Tecton.  First we install the Tecton pipelines.  You can see it's a few customer resources, config maps, all but you can find it on the  Tecton GitHub repo.  And you can already see we have two pods.  One is the controller for the pipelines and the other is the webhook for the pipelines.  Okay, we go on.  We're just going to install the dashboard so we can see something what pipelines look  like.  That's also from the Git repository of Tecton and there's a pod of the dashboard.  Okay.  And we need to install the ingress.  We need to ingress so we can see the dashboard on our cluster.  So that's all.  Now we install Tecton.  Okay, nice.  Now we installed Tecton.  But how does it work?  So Tecton consists of a few customer resources and the basic building block is a task.  It consists of many steps and each step is a container and a step can do stuff like create  a deer in a repository, a clone repository.  Very simple task.  The task is bundled in a pipeline.  It can be triggered by a pipeline run.  So whenever I deploy a pipeline run, the pipeline is triggered and the pipeline triggers the  task in a specific order.  You can define the order which task should be triggered after which task.  So let's have a look.  Since we already installed Tecton, let's have a look how it looks like.  Okay.  A very simple demo.  We have a task which is only doing echo and it will show the message.  And we have a task run which triggers the task to run.  Let's take a look how it looks like.  We have our three Tecton pods.  We take a look here to watch the task runs.  And we're going to apply those two resources.  First, let's deploy the task.  So we have a task in the cluster waiting for the task run to trigger the task.  And now we're going to deploy it.  Let's take a look here.  And we see the task run.  It's impending.  We are using a new pod which is starting.  And it took 11 seconds.  Let's take a look at the logs.  Hello, CUNP dudes.  You are successful.  You can see it here.  That's how the basic building blocks of Tecton works.  Task is triggered by task run.  Okay.  Let's continue.  We saw a task in the task run.  Let's take a look at some one step further which is a pipeline and a pipeline run.  So in the task demo, we have a few tasks.  Two of them.  We have a pipeline that is referencing those two tasks.  And we have a pipeline run which triggers the pipeline.  So similarly as before, let's take a look.  Task runs, pipeline runs, now none.  We have still our three pods.  So let's go on and let's deploy all the resources that we need.  Once we are going to deploy the tasks.  This one, you have these two tasks.  Okay.  In the cluster.  Let's continue the pipeline which is referencing the tasks.  Yup.  Pipeline in the cluster.  And now the last one is going to trigger pipeline run and task runs.  As you can see.  We have a task run and pipeline run.  We have two new pods.  One is completed.  The next one is starting.  You can see it consists of two containers.  Yeah.  And let's take a look at the logs.  Maybe let's take a simple one.  Hello.  You see the message.  Let's take a look at the other one.  Yeah.  It shows us the information about the pipeline.  It's the parameters that you get from the higher resources into the pipeline.  And everything was successful.  So that's how it is.  Very simple.  Tecton pipelines.  Very cool feature of Tecton pipeline resources.  Piping resources allow you to predefine resources that you very often use in pipelines.  I'm using the most the Git resource and image resource.  I can define from which repository to clone a repository down or where to push it, where  to push the image that was built during the CI.  There are many more resources.  You have a pool request resource.  You have storage resource, a cluster resource, and clothe event resource.  And there are many more coming.  We have our pipelines.  So let's set up our repository and create a web hook to trigger our pipelines.  So in GitLab, we just go to web hooks.  We create a web hook which is reacting on push events.  That's the only thing you need to do to trigger pipelines from GitLab.  Now we have the web hook installed in GitLab.  It's going to trigger our pipeline.  We have a web hook pointing onto our ingress, but there's nothing behind.  So that's why we have to use Tecton triggers.  It's another part of Tecton.  You can find in the same repository on Git.  And Tecton triggers is the building block between the pipelines and our Git provider.  First, let's install it.  Okay.  Let's go back to our cluster.  And there we go.  We have a YAML which installs the triggers.  You can get it from the Git repository of Tecton triggers.  Nope, typo.  Just let's apply.  Oh, I guess there's typo.  One more time.  Okay.  Let's install the triggers.  Here you can find in the Git repository where Tecton is.  It's the other part of Tecton.  Okay.  Let's apply the YAML.  Wow, it's a long one.  And you can see the pods.  We are getting two new pods.  The triggers controller and the triggers web hook.  Our Git web hook is going to point onto the web hook pod of triggers.  Okay.  We installed another thing, another part of Tecton, the Tecton triggers.  But what is Tecton triggers exactly?  Let's have a look.  Tecton triggers, it's the connecting block between the web hook and the pipeline.  You can see here, your Git provider, here's GitHub, but we are using GitLab, is sending  a web hook.  The web hook is being received by the event listener.  The event listener can decide, depending on the payload of the web hook, where to send  it to which trigger binding.  The trigger binding is sending it to the trigger template.  The trigger template has a pipeline run, which triggers a pipeline, and the pipeline  triggers the tasks.  May sound very complex, but it makes everything much more granular, and you can exchange all  the building blocks, and it works really fine.  So let's have a look.  Let's have a hands-on.  Let's go back to our environment, and here you can see the listener, and it's listening  to event type push hook, whatever we push something to our GitLab provider.  It's going to send a push web hook.  That's how the web hook looks like.  It's a JSON.  It has a lot of information about our Git repository.  It says it's a push hook.  The listener is going to only let the push hooks through, and let's deploy the whole  thing.  The listener, the trigger bindings, the triggers, and let's see.  We're going to look at the locks of the event listener.  Let's put enter, so we're going to see the new locks coming.  We'll try to use a curl, and we're going to send with a curl the JSON payload to our  ingress and to our event listener, and we will try to trigger the pipeline by this  curl.  And you can see something arrived at our event listener.  We have a new pod, a new pipeline run, and a new task run.  And everything was successful.  Let's take a look.  We're completed pod, and you can see here the pod consists of two containers.  That means a task consists of two steps.  Let's pick one of them.  Let's for instance look at our step run, which is showing us whatever is into the repository,  and you can see that's our repository.  Those are the files from our repository.  That's a simple example of how triggers work.  You can see how triggers work.  Let's take a look on the sequence, how the JSON payload arrives in a container.  You can see here with a red arrow, it's a straight line, but to get from a payload to  the task, you need to go over a trigger binding.  The trigger binding takes the payload over the value to the trigger template.  The trigger template takes the value to the pipeline definition.  And the pipeline definition puts the value into the task.  The task is a pod with a few steps, one of the steps of the container, and to get information  there.  For instance, you want to clone a Git repository in the task, and you need to know the name  and the commit ID of the Git repository.  And that's how the information is going from the payload into the task.  And actually, this is the ingredient that we are missing in Lighthouse.  That's why you couldn't use Lighthouse, because in Lighthouse, when using Tec-Ton pipelines  and not using Jenkins X, you cannot get the information from the JSON body into the task.  But with Tec-Ton triggers and Tec-Ton, we can trigger pipelines from our Git provider,  regardless of the Git provider.  It can be GitHub, GitLab, and others.  And we can use it next to Pro and Lighthouse.  Okay.  So we have a chat pod.  We have really cool Tec-Ton pipelines.  It looks like we have everything, but there's something missing.  We are missing a little bit magic.  And what is the magic?  Magic is Kevin.  Who is Kevin?  Kevin is one of the Tec-Ton lead contributors.  And Kevin helped me a lot, because I was missing one thing in my pipelines and my CI.  I couldn't see the pipelines running in GitLab.  So I was pushing something into GitLab.  And I couldn't see in the GUI any information about the pipeline.  I didn't know if the pipeline was successful or not.  I only saw the task runs and pipeline runs, which were saying they are successful or they  failed, but I haven't seen it in the GUI.  So I was researching, and Kevin helped me a lot.  In Tec-Ton, in the Git repository of Tec-Ton, you have one part which is called experimental.  And there Kevin showed me a very cool thing, which is the commit status tracker.  What is the commit status tracker?  It's another controller.  Basically, it's just a Docker container running.  And it watches pipeline runs, and then it goes to annotations, and it looks at the annotations.  You have to have specific annotations, like a Git status, status context, status description.  And depending on your annotations, the commit status tracker is going to report back to  GitHub or GitLab, and it's going to show you a pipeline running in your Git provider.  And as long as the pipeline is not green, you cannot merge your pull request, for instance.  It was the missing block to have a really cool CI system.  Yeah, let's install it.  We back again to our environment.  Before we go into the commit status tracker, as you can see, we have already a few ports  running.  So there is our YAML.  And here you can see the commit status tracker Docker image.  And it's very simple.  Let's apply all of this.  And you can see the four seconds our commit status tracker is running.  And let's try some example.  I'm going to deploy something with specific annotations.  And the commit status tracker is going to look on pipeline runs with those annotations.  You can see there's a status context, even a website that you can refer.  That means when I'm on the pipeline, I'm going to click on the pipeline in GitLab, and I'm  going to land on this page.  And here you can see a pipeline resource, Git, that needs two things, revision, and the  link to the repository.  Let's have a look.  Okay, in our GitLab, under pipelines, there's nothing.  It's clean.  Let's switch now to our tests.  We can apply.  We have a task pipeline and pipeline run.  Let's apply the whole deal.  And we couldn't get the pipeline.  Oh, yeah.  That's because we deployed the pipeline run before the pipeline was deployed.  Is it one more time?  Now, step by step, we delete the pipeline run.  We apply the task.  Okay, task is in the cluster.  Then we go with the pipeline.  So, we can cluster now, we can trigger the pipeline run.  Oops, one more time task.  Let's go with pipeline run.  Okay, we are triggering the pipeline run.  It's pending.  Oh, it's already success.  We have a new pot.  We have results.  And let's look at our Git repository.  And we have a pipeline which is already green because the pipeline passed is green.  And that's because of our commit to the structure.  Nice.  We have all the building blocks.  I think we have done now with hands-on.  And you can see now, we have an emerging bot, or chat bot, which is Pro using Jenkins X  Lighthouse.  We have a tecton for running our pipelines.  And we have a little bit of Kevin magic.  The commit structure to report the results of the pipeline's back to our Git provider.  Git provider.  Let's have a look.  There's this diagram which is comparing Pro and tecton.  So in Pro, you have a plugin called hook, which is waiting for the web hooks.  In tecton, we have tecton triggers with interceptors, even listeners, as we saw before.  For job execution in Pro, you have a plank.  But in tecton, you have pipelines.  Tecton pipelines.  In Pro, you have a dashboard, deck.  It's missing in Lighthouse because Lighthouse is not having all the plugins of Pro.  But we can use our tecton dashboard that we installed in our hands-on.  In Pro, we have tight for merging in tecton.  There is no tight.  There is no bot.  What we are using Lighthouse, which is Pro.  And that's how we are having a nice merging bot.  I think the nicest available.  For the big jobs, I haven't seen this, but for this, we can use triggers and Kubernetes  Chrome jobs.  Trigger can trigger a task, which have a Chrome job and a periodic job.  And for garbage collection, where we don't have anything for garbage collection, but  for this, you can use a simple Chrome job.  You don't need to use anything technology.  Okay.  So I believe that with these three steps, we managed to build up a really nice CI system  on top of GitLab.  We are not using GitLab as an app of all the apps.  We want to use GitLab as a Git repository, not as an engine for running pipelines.  With GitLab, we could use GitPocket or GitHub, as long as we are using Lighthouse, tecton,  and our small magic step.  We believe in the future, tecton is going to manage to create some better technologies  and to report the status of the pipelines back to the Git provider.  So in the future, we are not going to need any commit status tracker.  So then we just rely on our merging bot and our pipeline engine.  And in the far future, when you follow the select channel of tecton and how things go,  maybe we're not going to need a merging bot.  We can do, maybe in the future, we're going to have only tecton.  And tecton is going to do the role of a chatbot.  You could do it right now, you could use the pipeline resource called puller request.  And the pipeline resource could be modified depending on the comments in the chat.  There's something more.  There are a lot of them.  The whole tecton environment is much, much bigger.  We have cell interceptors so we can modify the JSON body incoming to the webhooks.  We have conditions.  We have a lot of experimental features like our commit status tracker.  There are more.  And I saw there's even a tecton result server which is going to keep our results of our  pipeline guns.  And even so, someone is working on a notifier.  There's also a tecton controller which keeps our tecton running but unfortunately it only  works with old tecton versions.  I guess the tecton people need more support.  And there's a tecton hub.  And from the tecton hub you can get tasks and tecton pipelines and you can even contribute  there.  Okay, that's how our tecton setup on GitLab is working.  I believe it's a much nicer setup of GitLab than using this GitLab CI.  Yeah, that's it.  Thank yougem for the time.  The famine of death  You  are you there?  Perfect.  Okay, I'm live.  And I can hear myself. So who's that the speaker of those not here yet. He might join in a second, maybe a month or it or young you could ping in.  And then we'll get to the questions.  I'll start with first question. I believe.  For some reason, the question is, I'm a pollinger.  I asked that he's not sure if he if he missed the pardon beginning but why Rafa is using an external CI solution and not the Github CI. I think the explanation Rafa gave in the end that the goal was basically to use the Github CI to the bear tool that the CI runner so to say.  Rafa, there you are.  I was in the wrong room. Yeah, why are we using the other technologies not get that CI.  First of all, I wanted to use pro and there was no solution for problem get lab. That's why I went with light house and then from light house I came to tecton. The other reason was, I didn't want to be locked in and get lab. So I want to be able to easily switch to get help order.  There were also other reasons I was working before with get lab and we use get laps. He eyes a lot.  And it was not scaling nicely because then you had the include of a pipeline which was including another pipeline at the end. No one knew where one pipeline was in.  Yeah.  Also from my experience, it was not scaling well enough. So sometimes pipeline were not starting and there were some issues. And with tecton I have all the pipelines represented as Kubernetes object.  I mean, you just look on your Kubernetes cluster and there's your pipeline. You don't have to go into your repository.  So that were the main reasons and my private reason was.
FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_0_167.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_168_623.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_624_719.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_720_851.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_852_971.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_972_1139.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_1140_2663.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_2664_3263.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_3264_3971.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_3972_4979.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_4980_5075.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_5076_8543.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_8544_10799.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_10800_12755.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_12756_12803.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_12804_13019.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_13020_13331.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_13332_16427.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_16428_17507.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_17508_17975.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_17976_20531.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_20532_23483.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_23484_27035.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_27036_27311.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_27312_29267.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_29268_33371.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_33372_34283.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_34284_38579.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_38580_38627.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_38628_38867.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_38868_44279.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_44280_44711.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_44712_50099.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_50100_51815.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_51816_59915.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_59916_59999.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_60000_60071.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_60072_60191.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_60192_62759.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_62760_63539.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_63540_63635.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_63636_64007.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_64008_64151.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_64152_64235.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_64236_64475.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_64476_65267.png FOSDEM2021CI_on_Gitlab_Bringing_Gitlab_Tekton_and_Pro_65268_65522.png