1:19 Introduction

1:19 Hello. And welcome to today's episode of Rawkode live. I am your host Rawkode. And today we're gonna be taking a look at TektonCD. A continuous build pipeline delivery software thingy majiggy for Kubernetes. Before we get started, I just wanna say thank you to my employer. I work for a company called Equinix Metal. They are a bare metal cloud. They provide the time, the resources for me to invest in the show and get experts from the cloud native community to come and share the technologies they're working on with us today. So thank you, Equinix Medal. If you

1:56 wanna try it out, you can. There's a $50 code or Rawkode dash live. This will get you roughly one hundred hours of compute. So it'll allow you to get a feel for what bare metal is and how to leverage it best to your cloud native architectures. Now today, for looking at Tekton, I am joined by Kevin McDermott. Kevin is an engineer at Red Hat and a contributor to the TektonCD projects. Hey, Kevin. How are you? Hey, dude. I'm not doing too badly. Awesome. Do you wanna take a a few moments to tell us a little bit about yourself? And

2:28 then we'll start talking about Tekton. So I work on GitOps at Red Hat. I'm building out automated pipelines to allow you to automate build and deployment into production. I've been writing software for thirty years commercially. So I've been around the block a few times. But most of the stuff I read nowadays is is really centered around helping people get software from idea into production as quickly and safely as possible. At least theoretically, at least. Awesome. Cool. So why don't you start by telling us what is Tekton? So Tekton is a project. Been around for, I think,

3:04 What is Tekton?

3:14 four, five years now and and it and it's basic part of it. I don't know. Maybe not. Not about two years since basic part. And what it does is is I I can keep native a cloud native, Kubernetes native pod scheduling. So what do you have a problem with now? You wanna run a container in Kubernetes? How do you get another container to wait for that container to execute? You can. Right? It's pretty difficult. You have to do something with Kubernetes or something. And so Kubernetes Tekton allows you to specify the order of things and you can split and and rejoin

3:46 processes to allow you to set up a series of events and containers to to be executed on a PVC or something like that. So maybe if you wanna build, like, a a build pipeline, then you always have to clone your source code. You might wanna run some tests, and then you start to build on top of it. So if you will have a continuous delivery pipeline, then Tekton is a cloud native way of doing it. It's also the kind of basis for some other projects. So they're forced to Jenkins X and things like that. They're

4:13 building on top of it. Okay. So, I mean, one of issues cases is continuous delivery. Does it also take the same box, fit in the same market as other services like like regular Jenkins, like CircleCI, you know, does it have a, like, I guess, a crossover and feature set with these ones or is it slightly different because it runs on our own Kubernetes clusters? So how do think? So I think the biggest difference is that it isn't by itself system. It's a way of executing containers and and and getting the results of those containers so you don't get the kind of

4:49 and this is, you know, it's not intended not intended to be like this at the moment and there is ongoing work. But you essentially get the results of executing those containers. So for example, like, I was saying, we're doing is we have OpenShift and we have some kind of nice UIs around them showing you, like, the results of those and we can gather up some results and you can see, like, what pipeline, what has executed and things like that. And as you'll see that there there is a Tekton dashboard which allows you to get a kind of nice visual representation of this.

5:18 Alright. Well, I am looking forward to seeing this. Tekton is one of those projects that, you know there are so many projects in the cloud native ecosystem. And I wanna be able to play with them all, I guess, like Pokemon, but it's just finding the time. So I'm really glad that we got to take a look at this today. Yep. Okay. Sorry, Nico. What you guys said? You know that when you open up that CNC airplane, you just think, woah. Sorry. I mean, I I like the size of it now because I'm like, cool. I'm

5:33 Demo Setup and Component Installation

5:46 not gonna run out of content for this show for a while. So, you know, selfish reasons. But certainly as an end user, someone that has to operate stuff in production, it can be a little bit intimidating. But for, you know, Tekton solves a lot of problems and I'm hoping we can demonstrate that today. Well, you can demonstrate that today. I just get to sit and enjoy. Alright. Before we get started, we do have a couple of comments. So first, hey, Andreas. How's it going? Wave, wave, wave. And rain. Hey, rain. How are you? Okay. So

6:15 let's one of the things I like to do at the start of the show is just see what was prepared upfront. And I like that to be as little as possible. Now nobody wants to watch me provision a Kubernetes cluster. So that has been provisioned upfront. And I have shared the cube contact for that with Kevin who will be driving most of the demo today and batting away all my questions at the same time, I'm sure. I'm gonna share your screen. Oh, we got Oh, that's okay. We will da. Cut you off guard. There we go.

6:48 So can we zoom in on that terminal a little bit? Sure. My eyes are good, but they're not that good. Where's that, Luke? I I would go another six or seven presses maybe. Okay. A couple more if you can. Yeah. Okay. Let me see if we can do this a couple more. I know it's gonna be yeah. Like, that wasn't too bad, is it? I I think that should be okay. Better than yeah. I think that might be okay. Yeah. Okay. So what I'm going to do is so doc, basically, we have a a blank

7:00 Installing TektonCD

7:27 cluster provided by David. So what we're gonna do is then we go through the the things that you need to have installed. If native things all have, know, a a big bunch of YAML to get installed. So the very first part I'm gonna install is this is just coming from the the Tekton release documentation is the pipelines part. So pipelines is slightly more mature than triggers and so we can easily do a simple control apply and it will source all those resources and get them coming in. How nice to be be on clusterable role bindings. That's probably something we have to fix

8:02 at some point. So this is version 0.18 Is that what we consider stable? That's safe for production people? Yeah. Okay. Yep. Yeah. I mean, it's not one point zero yet and there's no there's no guarantees around stability. So the next thing we install is triggers. So pipeline is basically your sequencing mechanism. You you as you'll see, you can define tasks and you can define pipelines and then we can execute those. Triggers is more about how do you drive a pipeline. So I'm hoping that we'll get to today actually having completed driving build and push of an image to

8:38 Docker Hub based on a change to GitHub. So let's see if can get that far. So that's what triggers is doing. So it's bringing in a couple of CRs. So it has if it I mean, as you're gonna see, this is pretty YAML heavy. There's a not a lot of niceness in some of this, is why. And then the very final part of this, I'm going to grab is the dashboard. And we do this. So we've got our dashboard going in. So dashboard is nice. So as you can see, the UI for it looks quite quite tasty.

9:08 So I'm I know we were talking about getting a an increase available for this. I don't know if you can do that. If not, I'm very happy to keep proxy it because keep proxy is quite nice. Yeah. I think we'll be we'll be keep proxying. So don't worry. You're not gonna you're gonna have to do we could do this very small because you actually have to see the screen. That's fine. So let's keep proxy figure here, then we should be able to see yeah. There we go. So this dashboard, so we've got as you can see Do

9:40 you have the main on this as well, please? Sure. Sure. Is that readable? Yeah? No. I can't read it yet. It's a new one. He's good. We're at 200%. Or maybe I'll bring my screen size. Maybe not. Wait. Can you see that? Is that reasonable? Visible? The menu is not readable, but the rest is. So I think we're okay. The menu is not readable by the Yeah. It's just it's just a bit small. But it's okay. I think we're okay just now. There's not much to see. Oh, there we go. That's perfect. 300 is where we need to

10:08 be. Okay. So very first thing I'm gonna do second thing I'm gonna do rather is create a very, very first task. So this is maybe a very simple task which I'm gonna put into file. So then oh. Let's look at this. So it's a it's a cube CR. So we've got this, you know, API version, part of the GBK stuff. So API version kind of task, metadata name. So obviously, name it. I'm gonna put it in the default namespace just now mostly because it's kinda simpler to work with. And this task is a single step that just has a name

10:10 Creating our first tasks

10:43 called say hello because you can have a name for these things. It's using Alpine, which can be obvious, I guess. And in this case, it's using a script. So this gets executed as a shell script on the inside the container that you pick. So we have we'll skip shell inside the open and we're gonna run this. So let's see. So I save this and k. I know you hit k apply but that's okay. No. It's k create. I don't like k apply is okay. Okay. It's regard creation. So the next so we have this thing.

11:17 So we can see if we go to dashboard, we're gonna see we now have a hello world task created 10 ago and it hasn't yet run. There aren't any runs for it, so it's not particularly exciting, but that's okay. So next thing we do is I'm gonna create a really simple task run for this. After this, this just and all of the materials will be taken about other I'll just open up the the repo that this is coming from. So let's create hello world task run. So the the relationship between these is, it's kind of like a class and

11:51 instance type relationship if you're a programmer. So you have like a task defined, here's the things that need to get executed and the task run is an instance of that particular one. So if if you're familiar with Kube, you'll see that we've got a generate name on this. I don't need to have a generate name if I wanted to keep it, then I'd have to go and delete everything and run it. And this basically just is a really, simple thing that says go and execute the hello world task. You see there's just a text script.

12:14 What we can do is we can do key, create. You do need to use create with generate name, I think. So so what we're gonna see here is if I click on this hello world task, you can see that it's doing its thing. It's pulling it and and we can see that it logged out. Hello, world. Right? Pretty much what we expected to see. So that's a really simple case, think. We need to say, you know, traditional from KNRC book, where we've got a hello world is our thing. So we can also, there's a command line component part of this

12:51 and it's installable through homebrew, it's installable from the binary releases and so we can do a TKN start hello world task. Oops. Oh, task start. Oh, if we can't if I could actually type. Nobody can type with people watching them, that's just the rule. It's a ticking task start and so you can see that that's just created a task run and done the exact same thing. So we go to our pipeline runs, our task runs here, we can see that our second task running and it's not gonna do anything different. Right? So we can do that. Tekton is nice because you can

13:28 do things like task run test. See this? Because these are really just group resources, which fits in those. And the thing that I like the most about this is you can do task run logs last and it will go and fetch the lot most recent task run and get you the logs from those things. And this applies to pipeline run as well. So we've seen that you can basically do a really simple task that's doing something. Nothing too exciting in this. Okay. Can I just summarize that back and tell me if I got anything wrong there?

13:56 So what you've done so far is the fans and the yaml, your task. Your task just needs a container image which we reuse in Alpine. We give it whatever name we want. And then you have the script at a property and the spec called script, which can run any command that can happen as a damage. Yep. So it doesn't do anything by default. That just creates a definition of a task. And then the second thing that you did via the TKN, we call it Tekken. Tekken. Tekken. I don't know. Is there official pronunciation? In fact, there's just

14:32 something I didn't ask you as well. What does what does Tekton mean? Let's answer that in a second. So you then have a task run which can be applied via YAML or via the Tekken. I'm gonna call it Tekken command. And that actually takes the task definition, runs it as a pod and set up a container and then gives us the outcome of that. That's kind of what you've done so far. Yep. So that's pretty much it. Basically, your task definition is your class definition if you like and your task run is an instance of that class and executes whatever the

15:01 behavior that was in the class. That's a kind of simple way to think about it. Obviously, there's not a direct analogy but it's task will not deviate from a a task. Sorry. Task run will not deviate from a task. So tasks that do one single thing are not actually all that useful, don't suppose. So what I'm gonna do here is I'm gonna need to update this task. I'm gonna give it a parameter because, you know, sometimes you just want to sometimes you just want to okay. So I'm gonna add a parameter. So you can see that I've added a single

15:25 Tasks with Parameters and Multiple Steps

15:39 parameter. It's called name because, hey, we're gonna greet someone here. It's a it's a string type parameter. The default is world because, you know, traditional. And we can give a description so we can see, like, who is it, what is it, what's the purpose of this particular parameter. You can name parameters any which way you want and you'll see there's bit of variance between them. Some people use lowercase and some people use uppercase. I tend to use a mix sometimes usually to differentiate between parameters that are the same because you may become you may be coming

16:06 in an input parameter or an output parameter, but you can choose to name them in which way you want. And so you can see that that on on line 16, you can see params dot name. So what that's gonna do is when it gets when the task run gets created, when it's setting up, it does a param replace. And so anything that's getting pulled in is a params dot name thing here, that will get replaced with the value of the parameter. It's just a string replacement. It's it's not anymore advanced than that. Does that make sense?

16:38 Yeah. Yeah. Yeah. That makes sense. I think that's just interpolating the entire script and dropping in all those parameters before runtime. Right? Okay. Yeah. So we can now do Tekton task start. Hello world task. You see that it's gonna say, like, can give us a value for the parameter name of type string. So you can create this with a pipeline run, you can obviously do it in in in the task run rather. And you can put it in explicitly into the ammo. But Tekton allows you to prompt for those things. So you can see that it's offering me the

17:11 default world. But, hey, you know, let's put in Rawkode in there. Okay. Awesome. So we can do Tekton task run logs last. May not have completed yet. Oh, yeah. It has. Awesome. Right. So you can see that we've got this Hello Rawkode and that's gonna be expected. Right? So tasks are really kinda simple. But tasks can have multiple steps. Let's you know, we can see where we're going next to this. So we can we can create a task once we can pass this in if we really wanted to do it. We're not gonna do that. We can change

17:41 our so let's add an extra step to our task. Right? So a task doesn't have to be just one thing, it can actually have multiple I don't even know why that's jumping a bit all over the place. With your hello world task dot yamo add an extra step in here. Mhmm. What's interesting about it, I guess, the thing that caught me at the first time I had to do this was you that that it uses a different image for each one. So these are obviously a complete separate pods on top of this. We you're gonna see what this gets generated as.

18:14 But we can put the same use the same parameter again, and this will get executed as a couple different pods. So if I do Tekton I think your HTML invalid. Oh, which actually I think your name, image, and script are all indented ones based too many. Yes. You're absolutely right. See. That's why I was kinda worried about YAML. I always worry about YAML. There's no YAML to it. YAML developer. Alright. So we've got our task we've been. So let's do we start on this. Let's do live demo. It will of course get past through and

19:00 oh, I haven't completed probably. We go. There are a few things. Okay. So and of course, if we go into dashboard, You can see your tasks coming up here. There's the the duration of them and you can see, you know, which particular pod. And these these just get executed pods. Does it show you the parameters that were passed to it as well? Good question. I know Tekton does. If I do Tekton describe describe last I definitely, you can see. So there's your parameters there. Does that show you the parameters? Let me see. It would be on oh,

19:42 yeah. There you go. So on the actual task, it's on the container. So you can actually see those things. And you can keep them by by by because obviously, they are pods. So if we do, like, pods, you'll see that we have one pod for each of the and and so some of those as you can see, hello world task run two two sevens eight five has two containers with it and that'll be this the hello and goodbye containers. Oh. So those actually ran as multiple containers and a pod concurrently and not one after the other? No. They run they run one

20:16 after the other. They do. Oh, they're good. Sequence a little bit, but these actually wait. It uses the downward API to do detection of when the the things are gonna execute. But as you will see in a bit when we get to, like, sequencing of of pipelines, yeah, you know, you you actually need it. For example, if you're gonna have a get clone task before you run your build, you really need to make sure that the code is completed before you start to build your code. So we'll have a look and see how that actually happens.

20:42 Okay. So where are we? So we're basically so the other format for this, so we create a slightly different task here. The other format you can use oh, I expected to download a complete, don't know. The other format you can use is you can put like a traditional YAML array type approach too. So you don't have to use a script. So you can actually execute a very specific command with a specific specific parameters. So I do git create. Start to execute l s. What do I call it? Hit it. Oh, did I not do it?

21:26 Execute l s. You did a cube create within them, but I'd that's I'm not sure what that did. Let me read and wait for it to complete before it is it. Let's make sure. Yeah. Okay. Yeah. There you go. Probably. And so we can put in so let's put slash in here. And logs was and it's probably yeah. There we go. So just exactly what you'd expect. We just executed. And as you can see from the task definition, it's just the same as everything else. The the parameter interpolation is just getting put into the array

22:07 slice of this. There are some complications around this. So you can have, like, one of the types you can have is a an array types parameter type. And you you kinda have to go and pull out the specific elements or there's some weird stuff around, like, expand well, expansion of of array slices of or slices arrays of strings. But you can also it's it's able to be you can go fetch a specific one when you can even do those kind of things. So Yeah. I would that's pretty trivial. So that's well, you know, just so you

22:38 know you're saying what you're gonna have a point definitions or whatever you're doing. So need to be thinking about it. So that's that. We have a question if you're happy to take that just now. Yeah. Go for it. Andreas is asking if we'll be covering the options for building container images. Yes. We will. Alright. Stay tuned, Andres. I mean, I mean, also, we'll see who so we're gonna use builder to do later, but I'm sure we will get to that. So this there's another thing that we have called this this is some so let's look at this one. So this is

23:01 Using Task Results

23:16 so the difference here is you get a thing called a result and the result is something that you when you execute, if you write to the path of the result, then whatever you write there is available to other tasks. Now this is a single task, so it's not so exciting. But first, like, you'll see in a bit, like, when you clone a git clone, when the official git clone task, it writes the specific URL and the shell of the commit that it cloned to results, which you can then use later on. So for example, you may wanna build

23:44 something that references those things and so you can do that. So this case here is a really simple example ish. It takes a repo and it goes to GitHub and then uses j q to work out what the most common, you know, the the the if you go to I don't know if you go to slash languages on a repo, then you get this map back which is the strings of all of the languages. You know, when you go to GitHub and you can see it. So this this will go into it and we'll put out

24:11 the top language. How useful this is? Probably not all that useful. But let's so good. Let's not wait. Actually, I could create complete this thing. There we go. Right. So it's the TTM task start top language task. And you can actually pass parameters. We can do recall equals give me a recall something you've got on GitHub. Rawkode slash dot fails slash no. Slash in Rawkode slash dot fails. Not actual little word. Yeah. Okay. It's Wednesday. Can you have we hide on that screen share thing just so it doesn't Sound you. Pull up the text. Yeah. It annoys me as well. Oh.

24:58 Thanks. Alright. Okay. So we've got a task run. In task run logs past. It should say, gender, gender, gender. So it's done. Yeah. Believe it or not. But with the Tekton task run describe, Last, you should see the what what language you expect me to be? Gender. Michelle. Well, I guess it's calendar too. Right. So top according to so what it does is it goes in the like, if you've never seen j q, j q is fun for doing this kind of stuff. But you can see, like, two entries, sort by dot value dash one, take the last one and

25:33 then get the key of that. So, like, you get two for today, you you get whether JQ works if you're really keen on it. I think it was very infectious and get you. So your your top language and your repo is clearly shale. So So you So this is using something on a task called a a result. What what are the primary use cases for that then? Is that something we use to to pass it other task definitions? Is it something is it logged hand is it logged differently in the UI? Like, what are what do

26:07 we get results for? Use for couple of different mostly, it's about getting things between between tasks in our pipeline. But you can oops. If I I remember to actually get the right thing here. So I get my task room. What was my what was my task room? You can I mean, because it's it's a standard cube resource of object, you can do this and so you can you know, if you wanted to run something and then get a structured result from it, you can do that? So we we can get our value back as Shell.

26:40 But yeah. I mean, it's it's essentially just writing a value in that you can then use later in a pipeline. So for example, you might get an auth token, for example, for something. So you might want to write that to the result and then pick that up and use that for auth and subsequent requests Because you can as you'll see now, we've been when we get to pipelines, can actually reference results specifically as parameter and and put them into parameters to be then called by subsequent tasks in the pipeline. Okay. So we actually have another

27:10 question that aligns really well to what you just said there then. Andres is asking, is there a way to put secrets into our tasks so that we can access secret information from Kubernetes or even failments? Yes. There's a couple of different ways to do it. We're gonna see a secret getting used later. This is something that I'll be honest, especially pipeline doesn't have it's not great the support for doing this for reasons that you've seen a bit there. And there is a plan to kind of make this a little bit better. There's a there's a big kind of discussion about making

27:43 secrets better for pipelines before one point zero, I guess. But you'll see how that works in a bit. I promise we're gonna get to doing a secret. So I'm gonna create a very simple pipeline. Okay? This pipeline here. So let's look at what this has. So this is a pipeline called demo pipeline. It takes one parameter, takes string and it only has one task in it. Right? So it's using the task that we were using earlier called hello world task. It's a task task. You get two types of tasks, you get cluster tasks and you get task tasks.

27:50 Creating our first pipeline

28:18 And so we're and it's unsurprisingly, the difference between those is one is cluster label and the other is namespace label. And you can so for example, how you build your docker images and things like that. Those probably don't vary very much across different environments. So you probably won't make those as a kind of or or the goal in code or anything. So I mean, maybe a lot of tasks I'm gonna show you today are could be cluster labeled tasks. But for the specific case, this is we're just gonna keep them all in one namespace and and have some point that way, I

28:50 guess. And so one of the things that we see is see that params part in the task reference, so just below the task. So what that's actually doing is it maps a parameter to the pipeline to a parameter to the task. So you'll notice that I deliberately called the parameter to the pipeline message. And what it does is it takes that message value and maps that to the name parameter to the task. That make sense? Yes. So our our pipeline has a parameter called message and we're passing that into the task as name. Yes. It means you don't have to have,

29:25 like, the same names and you you this is a really common thing through Tekton. There's a whole lot of things that use remappings, like workspaces and so many other things basically you see, like, here is this value and it and it I'll be honest, it looks complicated at first and and if you don't understand the exact reason for it, it's twice as complicated probably. But really what it's all about is you don't need to have standard naming and you could have pipelines or upstream have upstream tasks that you just use and you map how you wanna make your parameters

29:54 pass through to those. Okay? Mhmm. So this is our very first pipeline. So this is I need there we go. Okay. So we can create what's called a pipeline run. And to be honest, Tekton is creating pipeline run. So I'm gonna probably create a pipeline run. Oh, no. I'm gonna do it this way. We're gonna get to pipeline run the things. So pipeline start demo pipeline. It's gonna complete and so probably It's gonna ask me for the message. So let's put let's do our Tekton pipeline run list. Because we we should see it. So you

30:39 can see that it's running and we can do logs last and this wait. There we go. Awesome. Right. So it's just executing that task. We're going to our dashboard. We get to see our pipeline runs for a change and we can see this particular pipeline run here. Yes. So that's it there. And all it does is one task and passes that parameter through to it. It's kinda really simple. Pipelines basically provide sequencing for tasks. Can I don't know if it's something you're gonna show later, but it popped in my head? So I'll see now. Can can we

31:13 Pipeline Failure Handling

31:18 modify this the task definition and can we make it fail? Just for the yeah. Yeah. Just for the giggles? Okay. Could we do this? Let's think. What would what would actually call it to feel? Let's just change the task to run a command that doesn't exist. Like, instead of echo let's type one echo or something. Right? So Yeah. Let's let's do l six. Yeah. I don't think there's a command called l six, is there? No. See what I know. Yeah. We do actually. Oh, yeah. So why? Come on. On. Okay. It's we run that pipeline and you'll see what

32:04 happens. So we start demo pipeline. Let's just put demo see it in there. I think there we go. Awesome. Right. So it failed because and then a pipeline will fail if any of its tasks fail. As soon as a step, it returns a non zero exit code, then it fails. I'm assuming I can just get the logs out of that, see why it failed. Like, it's all self explanatory, I would imagine. It's actually quite nice because you can do if you do type click again pipeline run Last. See see. See what I actually say. It's usually says, like,

32:47 you know, state state space code 127 blah blah blah to see the specific logs for this. Must have listened like a real oh, because it's so big. It's getting taken off into the screen. If you're in a normal screen, what actually happens here is it shows you the the the control command to display it. I don't even do a scroller across from this for whatever reasons. It can't just create except for when it's not. You can just show it from the UI, I guess. Right? I mean Yeah. Yeah. That that message should be there too. Yep. You'll see that thing

33:20 there, but it it it will. Yeah. Perfect. So we exactly what we expected. If you modify it and you get I mean, it's it's really visible. You can see the nice kinda red thing here. So this is we can we can do better. Okay. So now we're gonna start to get into the the the image and the other bits of it that folks are probably really keen on. So there is a catalog of tasks available. So Tekton has this whole big catalogue with about five different build mechanisms. It's builder, s two I and build packs

33:35 Using Tasks from the Catalog (git-clone)

33:53 and various other things in here. So these are kind of predefined tasks. And if we go and look at the get clone task Can you just send that to 300%? Yeah. Thank you for reminding me. So you can see that this has a 0.2 and it has two things. So this it says here this task has two required inputs, the URL of the get reports clone provided with the URL parameter and a workspace called output. Okay. So we can see that these are the two things. And we'll talk about workspaces when I set this up to do it. But based on

34:25 our workspaces I'll say you last thing, so I'll do it. Workspace is in kind of shared space. So it's a PVC that's getting defined and that task executes. It's because this is why you can't use an empty door because if you did, you would end up with multiple p v empty door PVCs getting created. And this gives you kind of persistent storage to it's bound to the lifetime of the pipeline run to be fair, but I lose the, like, tasks to carry the things. So obviously, if you get cloned, you probably want to act on that get

34:54 cloned that you've just cloned. So what this allows you to do is to write it out and then have another task come along and pick that source code up and do the right thing. So there's a whole lot of parameters. I'm not gonna go into all of them. You can see that you can provide revisions, rest specs, sub modules, depth, SSL verification, which I think should be insecure as you know, and I don't like CSSL verified. What what it tells you and what it what it mean is really different. You can set up properties and things like that. So you

35:21 can do a lot of different things in So what we're gonna do is we're gonna take the this is the YAML for it. It's quite a big task here. I've looked at it a few things. Come on. Go to there. And you can see it's got a 32 lanes. Probably not what you wanna look at. So I'm gonna grab the raw version of this. Uh-huh. So the way that we use we consume tasks from the catalog, it's it's really just to apply them rather than, like, reference them within the YAML itself. Yeah. Because it's gonna be in the industry. There is

35:50 a couple of things. So I'm pretty sure Tekton has support for fixing them from from the catalog. But there's also a big bundle work going on, some quick site and stuff going on that's always you to, like, bundling to, like, add all of the various pieces that you might need for a task. So there we go. So we've installed our new and get clone task as you saw from the the catalog. That's what I'm now about to do here is I'm gonna build a pipeline that uses this. Okay. So it's then go to the old source.

36:26 That was a better promise if ever I heard. Build source pipeline. What you're gonna see is it takes two parameters. I've made them capitals mostly to help differentiate between the things that I'm passing in and the things that the task needs. You'll notice that in the past, the task said it needed a lowercase URL and a lowercase revision parameter. So my pipeline takes Git repo and Git ref and it takes those and and will execute the task. You can see that it creates this it uses, I think, called a work space. So this is like a declaration. So this is

36:59 I see that this pipeline has a workspace called shared data. But again, this mapping thing that we talked about, like, workspaces name output, workspace shared data, that's me saying that the, git clone source, which is using git clone, it should, get this shared data workspace, but they want to call it output for their purposes. So that's cool. We will we will map shared data to output for the execution of this particular task. Okay. So that's like, basically, a pipeline with a single task just now. All it's doing is calling that get repo and putting it in.

37:33 So I'm gonna build a source. I'm gonna do it like this. Oh, yes. Oh, you didn't apply the pipeline. Right. Okay. So it's a you know, handy here. So name for the workspace should be the this I mean, we can empty there for this one because we can we don't need to carry the source across. So it's an empty door, isn't it? Think this will work. Okay. So it's gonna go and grab the git clone task and do the right thing. You can see that it has completed. Awesome. Right. So not particularly useful as a start,

38:24 but log slash. You'll see that we awesome. So that's stored in there and that's our that's our first problem when we wanna whenever you wanna build something, you need to you need to source code somewhere. Okay. So one of the things I'm gonna show, we've talked about earlier is task results. Let me see what they're useful for. Oops. So they're bigger. So I'm gonna add an extra task in here and well, this is two things. Right? So this new task is called echo results. Number of easier to people to 26, you can see echo results. And so what

39:10 you'll notice is I've explicitly put it to run after clone source and I'm happy to take that out and show you what happens if you don't put running after. But you can see that it's taking two parameters, the commit in the URL and it's got a script that just echoes the two values. Right? So nothing particularly remarkable about this particular thing. But it takes its parameters to the task. This is like an embedded task. I'm not referencing an external task here. I'm referencing an embedded task and it's gonna take those two parameters. So you see the way that this is referenced

39:42 here. So this tasks dot clone source dot result dot commit. Unfortunately, the only way you'll know this is by looking at the task that you're executing, but this is seeing that lane 14 task clone source, it has a result called commit and I want to be passing that and it's a parameter to my echo results task. Does that make sense? Yeah. I mean, I'll try and summarize that back to you. So this is another pipeline with multiple tasks. I think what's different from this one is that instead of using task ref like we do in the clone source one, we

40:18 got a task spec. The task spec just allows us to define a task inside of the pipeline. There's an access to a variable called tasks dot and then the code source is just the name of the previous task. And then we can access the results and then the commit and then the results of the URL from it. So all connect links together via the task name and the task back is a nice way to know that. I mean, is task back something that you see people using for their pipeline trial and find the task separately? Is there any kind of

40:46 preference there? So, truthfully, guess it depends on whether you consider a task to be reusable or not. Like, for some things. For that, why did I put a task back in here? Because basically, I didn't want to write another YAML file. Don't have to find it. Then I can just do how much task is taken. So that's what I was doing too, like I guess if it's reusable and if you and and it's easy enough to refactor this so you can just extract it and make that task speak the speak of a task definition that you're rating.

41:14 So nothing would be particularly different here and we're just the only thing that we've changed is task speak and become task ref and whatever you name this. Yeah. So it's really it's a useful trick. It's I I guess, the paintings are kind of when we generate, like, paintings for the time for this. We cannot try to mostly task ref but for some cases, we would task make it. And if you've tried my Tekton CI thing, it generates huge gamos with all embedded tasks and pipeline runs in the rhythm. What I'm gonna do here is we do keep a play on it.

41:48 I should have done when it was in boom, but there you go. K. And I'm gonna run that pipeline again. Me know what works. I will see how it goes. There's in task run logs. And what I'm gonna do, once it's failed, once it finishes, I'll go back and show what happens if you don't put one after because this is this is sequencing. Right? So you need to wait for the first task to finish generally. And so, Tekton. I pick my mom. Oh, yeah. So you can like pick from here. That's pretty cool. Should see and there we go. Right. So

42:35 our our task is executed and all it says you can see, it's just echoed the two values that we were expecting to get here. It's nothing don't think about that. Okay. So we're gonna start to get into building an image from source. So there's another task and Do you want to remove that run after first? Just so we can see. Oh, yeah. Yeah. Yeah. I was excited for that and then I felt like you were gonna take away from me there. Right. So we do this and go go ahead and use them for everything. So it should apply that. There we go.

42:50 Building Container Images (with Builder Task)

43:13 Let's do that run again. Oh. Yeah. I don't know why it doesn't just default to that. It's possibly a bug. Anyway, so we're gonna do this. I think it will know I think it's a bit confusing because it's not obvious. We give you oh, yeah. Yeah. It's p t n task. It could get result. Think this may just be let me see. Oh, did I actually reapply that thing after I changed it? I don't recall. How much I I think it may just be lucky. So is there a race condition without the run after? Okay. Yep. We can get into

44:19 it. Let's say you avoid race conditions. And so, builder is this new task that we're gonna use. Right? So builder takes a git repository that has a a Docker file in it and it it builds it and then pushes it to git repository. So this is kinda really so it's it's an image repo. So you can see that you've you've got given an image, override the builder image, the path to the Dockerfile. So that just kinda assumes that it'll be in the top label of your repo. You can pass a whole of extra parameters and and arguments to it. So for example,

44:20 Building our first container image with buildah

44:53 you wanna add them, we we will be using this for is for doing extra labels on an image. So if wanna, like, label it with a commit and who committed and the details that can be getting from a commit here. So you can see that it's gonna take a source and it's gonna work on top of that. So I'm gonna steal my oh, yeah. I'm do it like this. So first of all, I'm gonna do the the apply. So that'll work. Awesome. I will need a secret in your k. So I've got a secret created. And

45:22 Handling Secrets for Registry Authentication

45:30 what I'm gonna do for this is I'm gonna grant access to that secret, the Docker config secret type. So I'm gonna add this to the default service account, which is probably not that great, anyway, we'll come back to this thing. And I'm gonna need so let's oh, source pipeline. So let's look at what we've got now. We have task clone source and we have a task build image and build image runs after closed source. References the task, the build image and it takes our param image that we wanna do. And it's pretty pretty simple. Builder, as I say, just takes your Dockerfile

46:16 and runs, I think, called Builder, which is our bug rather, which is our tool for building images inside containers. Yep. So if we do key, it's deviation for control to key. And so let's run this builds. I need a secret. There's reason I need a secret in there is because I wanna which image to it could be the I demo latest. That should work. Yeah. Yeah. Now this might take a little bit of time. Yeah. Sure. Put some there. Let's see. See that this is pro oh, parameter missing. Oh, I know what I did wrong.

47:18 Well, we let's see what this is. Then, really, let's let's say, he can pick actually, the parameters I'm screwed on. Last thing, you see it's missing the image param. So pipeline run to full parameters. It's missing some parameter. It's missing some parameters source image. If you look at my command line, minus p is how you specify each key value parameter. And I forgot what p I need there. So that's cool. So it keeps asking you for the workspace, the sub path. I mean, is there a way for it to not ask that? Oh, I can't think about I don't know

47:55 where we have it on Tekton. So the way I normally do this is by creating a pipeline run and just as I did with the task running earlier and you can then do the whole thing and then you're just kinda creating it because it doesn't change over the noise cycle. Oh, there's a nice typo there actually, which I haven't noticed before and it's empty here. Okay. Well, maybe fix that. Yeah. You take it someone who took in and pipeline run logs last. Running, so this might take a little bit of time. Oh, yeah. I mean, that's actually

48:26 building that container image with both on there. Right? So Yeah. Yeah. I mean, I think maybe looking about a minute or so. Oh. Oh, no. I've I've been in the what it is. You get code succeeded. No Docker file? Yeah. Great. So I know what it is. So this is I'm gonna build this is we do need a pipeline run for this because it's multiple containers. I think that this is really just a limitation of Tekton. Just now, had a conversation here since I'm in didn't quite get what I was going. So so what I'm gonna

49:13 Shared Storage (Workspaces/PVCs)

49:13 do here is I'm gonna write a pipe I've got a pipeline run ready for this. K. So let's do pipe build source pipeline run dot yamo. Mhmm. What I'm gonna do is here, gonna create what's called a volume clean template. And that's what it really is is a way to clean a bit of your PVC space. Right? So I'm just gonna grab a gigabyte. Sorry. Dude, if you get more of that, you're at least not more in trouble. And then we change this to push it to it's gonna do all the same things. Right? It's nothing not any different from the PV.

49:51 It's say for this, it's gonna provide PCB back into and if if you think about it, empty doors are for the light span of the pod because we have multiple pods when we for each of the the steps or each of the tasks and we are okay. Create I guess if almost like a pound doesn't fancy. So we have a question which I think fits some of what you're doing right now as well. So just to clarify, the PVC template, the shared data PVC that we're sharing across the pipeline is specific to that run of the pipeline. Is

50:28 that right? Yes. So Andreas is Andreas is just asking, is there a way for us to actually have global state that we can inject onto multiple pipelines for cache libraries? I guess, like, composer caches from PHP, pypi from Python. Yes. You can. So you don't if you don't use a template so what so there's two different ways to specify a volume for a a pipeline run. You can be explicit and actually just reference a volume and and and the get clone task will allow you to get code even if the content already exists. You can create a parameter option to

51:00 that. So you could share the same p b c and do a git clone and then, you know, cache and see if use an order or something like that. You could cache the the results in with that. So, yes, you either got templates which are created and are tied to the lifespan of the pipeline run or you have a fixed volume and you can just mount that in any pipeline run that you want. Nice. So let's see where are we. Let's see where are we. Where are we? We're still running. We oh, wow. It's quite impressively. That's hardware you've

51:28 got running at it. Parmel Parmel is the only way you run Kubernetes. I'm not I'm I'm not even doing that for a week, you know. And so let's go oh, I've got to log in to hub.docker.com. Here, this is not gonna be fun. Okay. You just have to trust me on this. There's a Christian image. This is gonna create a whole new profile, so I didn't have more my history. Not that my history really That is actually pushed to the to the docker hub. Right? With your credentials. I mean, you don't need to show us

51:58 that, but I guess you just created a secret inside the the cluster that Tekton has access to. Yes. Okay. That's why I choose that earlier. So, basically, you did that here, you you saw the thing where did it, right, so you can do it here. Right? So create a secret from your from home Docker config JSON. Right? So it needs to a Docker config JSON. Yep. And Tekton will automatically make sure that that's available as your config JSON, which is you're off to pushing up to GitHub. GitHub or to whatever your your thing is. And so, essentially, it takes the secrets that

52:29 are associated with the service account that's actually doing the work and we'll we'll bind those things. So it's kind of fairly simple. So we got our image, but I mean, as you can see, it didn't take all that long to build, did all of the Dockerfile compilation we're good to go there. Okay. So that's the so let's I'm gonna do one other thing here. Right? So what I'm gonna do is I'm gonna add a a test task in. It's what I call this code. Go test task dot yamo. So it's because, you know, generally, you don't just build code,

52:48 Adding Test Tasks to the Pipeline

53:02 you probably went all into it beforehand. So what I've got here is a really, really simple go test task. So what does it do? Does a mod setup to make sure that all of our things are pulled. It runs GoVet. It runs CILint and then it runs go test on the source code. And so if any of those things fail, then we want our pipeline to fail. We don't wanna build the image if, you know, if the code's not good. So what I'm gonna do is oops. I'm gonna do a kube create. K. So this is gonna create that task

53:32 for us. And then what I'm gonna do is I'm gonna go to the pipeline, which is the build. I'm going to here. Almost do this one by hand. But then if I if I screw it up, I'll spend ten minutes trying to figure it. So let's put this in. So I've said that check sources, check source should run after clone source and it it just maps in the thing here. But what I want build image to do is to run after check. So k. So we've got the sequence. We're seeing it. Clone it, check it,

54:13 build the image. That makes sense? Yeah. Pretty pretty standard build process, I guess, for most people. Yep. It's okay. Yeah. K. So now we'll just wanna we'll get a new pipeline run. We would be yes. Here. Do Tekton pass by they should hopefully feed. Yeah. I'm going to feed. And the filling test, which we used to show how to get up. And we're we're doing okay for time, I think. Yeah. Maybe we'll get there. Let's keep that first. So can you just run keep control get task run? What that also works. Right? I mean, are all just CRDs.

54:58 Yeah. Yeah. Yeah. I see. Let me get there. Yes. Cool. I like it. Yeah. So we I mean, they are just CRs. Tekton is nice because it gives obviously some localized knowledge to the the actual output of the things. But ultimately, you can just the right thing. So let's see. Where are we? Oh, where were the task room listed here? Oh. Yep. So it's still running. It's right. I guess it's in a bit a bit more last time, isn't it? Mine as well. I guess I mean, is there a way for us to find out what

55:32 what task is on right now if it's on the the the run? Yeah. Should be able to see awesome. Right. So our code is broken. Deliberately so I promise. Your code is broken. Mine's the same. Okay. My code is broken. So we will come back to fixing this once we start to go down the event listener and we'll see how we can by pushing this, we can trigger a new build automatically. So it's easy enough to insert tasks into the pipeline. And what you'll notice is if we look at it, that it didn't execute the image build. Right?

56:06 So you can see that it it did the clone, it did the go there, it did the go test, and then it failed at that point. And if we go to the dashboard, and look at our pipeline runs, you can see that it builds towards pipeline and it has field. So you can see that it got where it got to and which bit field. It's quite nice. Dashboard is nice. TKN is nice. Almost all of these things are just providing views of the cube resources as you can imagine. K. So all that's quite cool. So what do I wanna do next? Great.

56:30 Triggering a build from GitHub events

56:38 Well, we're gonna look at an event listener. An event listeners are part of Tekton triggers, so they're the kind of other side of this. So the very first thing I'm going to do, I'm going because I'm gonna cheat a little bit here. Right? So I'm gonna grab this permissions dot yamo. Really, this is permissions to allow Tekton to execute containers in the default namespace. You always have to go to Tekton pipeline's namespace. But there's reasons for, like, it's just easier to cheat like this. So we need to do a keep a control apply. You can

56:40 Tekton Triggers (Event Listeners)

57:11 go and grab the permissions if you want to. You see it's create demo role and a demo cluster role and a demo role being done and a demo service account. There's nothing tremendously remarkable here. So what I'm gonna do is I'm gonna grab this event listener. So let's look at what this is. So this is an event listener. So an event listener is basically a way for ingress for for JSON bodies to come in and to trigger something. So what does it trigger? Well, in this case, there's no filter. Okay? So we just get this thing that says whenever you get

57:42 something that comes in, use the bindings, which we're gonna see in a second. In fact, I should probably bind them all together in one file. No. I won't do it with that. You can see how that could go badly wrong. So we've got this binding and template. So once you see what a binding looks like, these make a bit more sense. I'm gonna steal it in here. Binding demo. So metadata demo binding. And so this is our our main binding, which we referenced in the the event listener. And so this is, whenever you get it, go

57:56 Trigger Bindings and Templates

58:20 and extract. So what we're gonna do here is this this thing here, body is adjacent path specification. So this is go and get the body which is provided as the JSON whatever the HTTP body only works with JSON, though, because let me remember. It doesn't support anything other than JSON. Yes. So this is what the JSON body that you receive will have a message key at the top label order. So extract that out into a parameter called message. Alright? So that's kind of obvious what that's doing. And then we're gonna create this template. So templates are a bit weird because they are

58:52 very powerful, but also, please. So what this is is this template needs a parameter called message. It's just a description message. I was really bored earlier. You can tell. Right? So we got resource templates and so the resource templates are think of these like like YAMLs for pipeline runs and things like that. And the only difference is they get dynamically evaluated when the trigger is executing correctly. So in other words, and what it really does is it extracts the values from the event listener. So it's it's from the binding, well, so it's demo binding. So it extracts that and then it puts

59:33 it into the pipeline. So this thing here, t t, so trigger template dot params dot message. Okay. So it's gonna call our demo pipe in from earlier, the one that didn't do very much. It just passed through hello world and it's going to apply a pipeline run for it and extract the body from some JSON body that we're gonna fire at it and execute that pipeline. Instead of doing, like, t k and run and put in a parameter, we can do the whole thing. So let's do t, apply minus f demo template. This is gonna be boring. I can see

1:00:05 why I was thinking of doing it. Binding. So remember. We've now got this thing. So let's do k get all. K get pods would have been poor. Actually, services would have been even so we can see that we've got this EL demo event listener here. Yep. Okay. So it's listening on port eighty eighty. And so this basically waits for HTTP requests to come in. So what I'm gonna do is I'm gonna very quickly do another very key port forward. Do I have to be to read this one? Service, Yale demo event, listener, 80. Should do yep. Okay.

1:00:55 And what we're gonna do is we're gonna need Carl to send the body. Okay. So you can see that this is gonna be content type application JSON. Message is coming from JSON to HTTP local host eighty eighty. Okay. So if we know Tekton pipeline run west, should see oh, do we we broke it earlier, didn't we? We did. And we didn't put it back. Okay. Well, here we go. But I debug it in there. Have to get in pipeline run. I Probably still trying to run the the field dash Rawkode command. Absolutely. Tim. So we we have a couple more comments

1:01:43 while you fix that So first, Thomas says, hey. Hey, Thomas. Nice to see you. We then got Vincent who says we can pass dash f to follow the live logs of a task run pipeline run, I guess, which is cool. And then Andres is asking, is it possible to run build without being a privileged container? There is ruthless builder. So it's definitely possible. However, I'm assuming Vincent maybe works on the Tekton project. He's also just said that that there's some limitations with the current version of the task, but that's about to change. So it sounds

1:02:20 like rootless container building container image building with builder is coming soon, which is cool. So params. Name, I think. We're getting some more security. I should admit you break that task earlier. I'm sorry. Mean, debugging is hard. Like, well, I mean, so we're gonna get our Tekton pipeline run. This and we should see it being successful. I think it's right. So this time, as you can guess, because the JSON says from JSON, we're gonna do Tekton pipeline run logs last. And you should see k. So if we do a quick k. Get log deploy l demo event.

1:03:19 See what actually logged out. So and this is for debugging. Right? So you you you you're getting I'm debugging things. So it says here, like, it it created a resource Tekton dev v one beta resource with a message name from JSON. You can see that this is the kind resource stuff. If it fails, you will get messages in here complaining bitterly about whatever the problem is that you've just triggered. Usually, the one area that it can be difficult to debug is if you're not totally familiar with the body, the JSON body that's coming in and

1:03:49 you're gonna come I'm gonna come on to show you some more like, cooler bits of this. We'll go for another five minutes and see how far we get. So basically, we have it and we're running pipelines from things. So there is a thing here called the GitHub interceptor And what it does is it takes, like, GitHub push events and allows you to off them and then decide that you only want to run on a push event. Okay? So what we can do is let me we yeah. We'll see how do for time here. Right? So we've got

1:04:00 GitHub Webhook Integration (Interceptors)

1:04:17 a very quick one. So this just means that we can use this GitHub interceptor that whenever we merge to the main branch, we send something to Tekton, which triggers the trigger. Yes. So this here says use the demo account. So you then get so what this is gonna do is also gonna validate the web hook come from GitHub. Right? So it's like the secret name and secret token here are ways of saying that the, you know, that web GitHub can sign the the body of the web of the request and so it sends you a push event.

1:04:55 So this kind of thing here says, like, you know, make sure that it's coming from GitHub with our shared secret and it's a push event. And we'll give you a slightly different template and binding. So let's go with the in here. Called it. One of the nice things about this though is that you can make this kinda compatible with multiple upstreams. Right? So when you think about it, GitLab uses pretty different JSON bodies, but it's the same values that really like a commit and a URL or the kind of things we're gonna get from it. So

1:05:31 you can actually kind of write a standard build template, but but how you can get the parameters to run that template can be different. So we've got our page. So this is basically, like, body head commit ID and body repository call neural. So these come from this. So you can see, like, if we look at the push event commit just a little bit more. Yep. There we go. So let's see what we get. We're getting body dot head commit. So if we look at head commit, you can see you're gonna get, like, an ID coming in. Yeah. So we're gonna get

1:06:06 a SHA and they get repository URL. So we're gonna we'll get clone URL. So that's actually get it from the hook event, like, coming in if we want to. Yep. The last part of this work here, and we're hoping to get this build finished, so we can fix this for build, will be build code template. This here, I think it there we go. So this is a template that is gonna extract the oh. Yeah. Yeah. It's okay. I'm just checking something. So this is gonna extract the image, the the the repo, the ref from the

1:06:49 hook request and then put the image. You can't really hear there are you can with a more advanced thing that I'm probably not gonna get time to get to today, but that's okay. But you can actually use like sale to extract some of these fields and then use that to to work out which image that you want to touch the to where to. But we can see that we're gonna get some bits extracted from the binding and it's gonna put it in k. So what I'm going to do is k. Get I'm gonna do that real listener so I

1:07:18 can And then I'm gonna bring it in and look, and then we'll see if we can get a build from a push with GitHub. Cool. How we how long we got? Two, three minutes? Okay. It's okay. Wait. Yeah. Oh, demo. Cool. And so, k, create that was k. Create build code template. Definitely, it'd been even cooler, wouldn't it? Yeah. Cool. Main safe GitHub push binding and create main safe GitHub event listener. Remember that the GitHub event listener is really just the only difference between that and the previous one is we've got this interceptor that's saying, like, only allow GitHub requests that

1:08:05 have a valid secret and that are push events to come through here. Okay? You can it doesn't have support for picking out branches or any of that kind of thing. You can do that. Don't worry about it, but not with the the GitHub secret not with the GitHub interceptor. And what it says is like and so an interceptor basically says, if any these return an error, then don't use this trigger and you can have multiple triggers. You see, this can be duplicated as many things as you want with different templates and different bindings and you just detect which one you care

1:08:35 about and then execute. So all of the ones that where the interceptors don't reject the request will execute. So if you've got, like, 50 inter triggers in there then, you know, 50 could actually start to execute at the same time. Yep. But probably you don't because you filter them out. And I can write my own interceptors. Is that think I mean, there's I mean, in for that actually. To be honest, sale will probably cover about 90% of your use cases. So there's a Google expression language called c l or sale. I'm gonna run the run the service that was running.

1:09:18 So you can do it like that. So let me just do a quick end drop. Oh, yeah. That should be okay. I will restart that. What I'm gonna do is what's my my port here? Oh, it's not yeah. It's not it's k get services. Right now, Kevin's just angry, because you want to be able to have to get a hub event go to your machine and be forwarded onto the Kubernetes cluster, because I gave you a Kubernetes cluster with no ingress. Yeah. But don't worry about it. Doesn't make you a bad person, dude. So let's go go demo.

1:10:18 End-to-End Demo: Git Push Triggers Build

1:10:19 Let's go to this is so big. It's really well. It looks great for us though, Kevin. So You know, for me it's like, where are we really so let me oops. Let's see. Let's see. So let's do this. P load URL. So this is, as you can see, just a standard webhook and GitHub. So what did my what did Ingram get me? It got me I run Ingram. Yes. Let's grab that. Here's in the darkness. There we go. Come on. Oh, jeez. This is hard. There we go. That yeah. Or not. That's it. Got it. Okay. So

1:11:03 let me pop that in here. In secret, because I happen to know what that is. And so this is just like, you know, push events and and things like that. So Yep. That's gonna be cool. So if you remember right, we there was a bug earlier in the test. Remember the code that was failing to do it? So what I'm gonna do is I'm gonna do git checkout minus b fix demo. Package demo handler test. Let me see. So is written for another thing. So what we see is f radius URL equals empty, key dot skip.

1:11:56 I'm gonna make this return empty if there's nothing. I don't really care about it. So let's say go test up and make sure that actually runs in between them. See that in there? So we can, you know, that's good. Right? So let's do git.git commit. Mainstream. Text stuff. Push. It's gonna complain. Get get push. I should really see it there as an option. Yep. Had it at some point and then every time I change machine Right. So I've just done a push. So if we go to our web hook in in giant form, we should see a recent delivery. Excellent. Right.

1:12:39 So that means it's it's simply push on to Ingrok. Ingrok will then take that and forward it to your bare metal cloud thing. And now, if we do Tekton, Tekton run this. It's awesome. It's building a source. Right? So Tekton, Tekton run, logs. This could take about what? Forty seconds or something like that. Add the dash f flag and we'll follow along. Let's see if that works. Yeah. Thanks. Yeah. Yeah. Yeah. Can we do that one there? Awesome. So you can see that it's gonna run the test and see the field maybe or not. Thank you, Vincent.

1:13:25 I was chatting to you yesterday anyway. Right. So, you know, our tests are now passed. Test has passed. Yep. So it's going to the build. The build. Build. Yep. There we go. Nice. Very cool. So we're at fifteen nineteen. That's not too bad for him. We'll probably finish out of that. If you're really keen, I can do a second part of it. There's all the other stuff that do. So we sell and stuff like that. But we, you know, an hour and fifteen minutes is probably long enough for most people's attention span. This is good. Good. Get registered to UBI.

1:13:56 Demo Wrap-up and Q&A

1:13:58 I mean, we can fix that. Yeah. That's awesome. Really really cool. Great. So we just pushed them. So what we did there was we configured Tekton to receive so let's go back and look at our our things. We we have GitHub event listener. So it will check for pushes and it will validate the incoming hooks. It then hands that off to the GitHub push binding. That's what you're pulling out the commit and the clone URL. That then goes to the github to the build codes. I call it I tried to call it that to to see that it

1:14:36 really is kind of generic as long as you can get a git ref to it and a source URL, then it can create a build for you. So you can see that that then passed through and and did the right thing, creates a volume and and does all the things. This is let's go look at our on our dashboard. We should see our pipeline running here. There we go. One build source. So it took about a minute and thirty nine seconds to build. It's not too bad actually. And that's including all of the checks and

1:15:05 things like that. Alright. Perfect. You know, we got to we did get to build in source code from from a git push which was what I was aiming for. Trust me, I had like I always stuff like sale interceptors debugging Versus code Versus code is quite nice on this. You get like some pretty cool UI, shows all the tasks and the pipelines. Or what I believe is a pretty cool UI for Versus code. That's alright. Is there anything else you wanna show before I pop your screen off? No. No. I think we'll Alright. So that was that was awesome. It really

1:15:43 could see Tekton working start to finish including that. Get help where put coming in, building, pushing, all of that. The PVs for carrying the state, the sequential ordering. Lots of really useful information there. So thank you for putting that together. For the people watching, the guest and the repositories that Kevin's used will stack in the show notes so you'll be able to follow along. And I think we can just finish with a very brief question then that we didn't ask at the start is what does Tekton mean? So it's ancient Greek for craftsman or artisan

1:16:06 Meaning of Tekton

1:16:17 and so, like, you know, don't keep a Greek name for things when you're building a a docker thing. Either that or some weird ship related they opted for an ancient Greek for craftsman. Yeah. It's just kinda nice to see. We must be running a nautical puns for names or products by now anyway. So alright. Well, thank you very much. I know we went a little bit over. I think you've you've taken time out of your day for that. So just, you know, thank you very much for joining us, for sharing that. I hope you have an awesome rest of

1:16:35 Conclusion

1:16:43 your day, and I'll hopefully speak to you again soon, Kevin. Thank you. Thank you. Bye. Cheers. Bye.