 Hello, welcome to Jenkins online meetup. Today is July 20th and we will have a pipeline as YAML plug-in introduction by Tunch Bacon on the call. And yeah, this is one webinar. We will mostly focus on demos and after that we will have a long Q&A session. And if you're interested to know more or to discuss something after the meetup, you can stay online. We will grant everyone voice permissions and we will be able to have more discussion. Could you please switch to the next slide? Okay, just to quickly introduce Jenkins online meetup. This is a community driven event. Basically, we organize meetups to speak about various aspects of Jenkins, including using Jenkins, developing Jenkins. We focus mostly on various key studies, success stories and we invite everyone to participate during this meetup. So please use Q&A to ask questions and please share your feedback because one of the main goals for these meetups is to actually get your opinion and your inputs about how we could improve. For example, in this case, pipeline as YAML plug-in game or how we are going to improve Jenkins in general and we will appreciate all your participation in this meetup. Again, the main focus is to do hands-on demos today, so we're sitting for live presentations and we're always looking for speakers. So if you want to present something about Jenkins, there is a link, Jenkins.io slash events online meetup speaking and if you want to share anything about your use cases or about your plugins, please you're welcome to do so. Thanks to our sponsors, second is delivery foundation and clubbies. They help us to run the infrastructure and cover costs for running this meetup. I guess that's it from me. So, Atunc. Yeah. Thank you very much for the introduction. So thank you all for joining this session. I am Atunc Pekan. So I have been working as a DevOps engineer and also I have been using Jenkins for the last 10 years. So I can say that I made DevOps and Jenkins interesting. You can just contact me if you need about the details of the plugin from these social medias. So during the meetup, you can always ask your questions with the Zoom Q&A session. And also after the meetup, you can check the pipeline authoring seek website for weekly events and also decisions on the pipelines. And also after the session, you can use this feedback form to provide your feedback for the session. It will be appreciated. So today's, I'm going to introduce the pipeline as a plugin today. So our agenda is that I'm going to provide some details how it works, completed features and the plan features for the future. And also I'm going to switch to the hands on tail with some of the practices that we can or you can use your in your pipeline. So pipeline as you know, there's one important situation that currently this plugin is in the incubation stage. So what does it mean a the changes on this plugin may rely in time or can affect the usage of the plugin. So that's why we always encourage people to use this plugin in not in mission critical or production like environments, but mostly please use it in like development or staging environments for that. We do not want to affect anyone pipelines or working environments. So pipeline is enabled, enables defining Jenkins pipelines in YAML format. YAML is a very well known format in these days. So this plugin can be used in multiple branch pipeline jobs. And also it can be used in the pipeline job is a a CM or in a secret in the editor itself. I'm going to demonstrate how it will be used. Also from the link you can reach to the website of the plug himself. So how it works, plug in converse YAML definitions into decorative pipeline format in the runtime to provide more details conversion happens after you check out the YAML definition from SCM. It converts to the decorative format and it injects into the flow of execution before running the pipeline itself. So you can think this plugin as a runtime converter of YAML definitions into the decorative pipeline formats. This is of course also same in the when you define your pipeline in the editor. So it is again converted into decorative pipeline format in the pipeline itself. Completed features. So until the latest release, decorative pipeline directives that are listed below is complicated, which means that you can use these directives in the pipeline as YAML plugin. And also, in the other concept, there's a converter for converting pipeline is YAML definitions into decorative pipeline, and also validating this converter decorative pipelines. The reason behind this conversion is to provide some pre validation before going for the real implementation of the pipeline as YAML so you can easily convert your YAML definitions decorative pipeline and see how it's going to be worked in the real pipeline. So this conversion helps us to use all the predefined steps or directives in the plugin itself. So for other plugin developers or for all the other custom steps, you do not need to define something special in your plugin. So every step is defined on the pipeline syntax helper page, which I'm going to show that can be used in the plugin itself. Plant features for the future so currently only metrics directive is not supported yet, but it is in the plan so probably in the few next releases we are going to support it. And also another plant features that converted from decorative pipeline to pipeline as YAML. So I believe this will be so helpful for the people who wants to use the pipeline as YAML with the current decorative pipeline so it can be easily converted to YAML format. And also I'm planning to develop some IntelliJ idea plugins, which will make it more useful for the defining pipeline specific attributes and keys in the IntelliJ itself. I don't know if I could jump in real quick. This is Liam. So the plugin for the IntelliJ sounds awesome. The question I have here is about matrix. Why, why is it not in yet just kind of what was, if you're going to talk about that at school I just wanted was wondering if that's a So, especially the reason is that I never use metrics. So first I need to use it in the pipeline to understand well. I had no experience with the metrics usage in the decorative pipeline. Okay, so that's why I didn't do it yet. But of course, as Oleg mentioned, seriously, all contributions are welcome. So if you have some experience with the metrics, decorative pipelines, you can always contribute to this plugin also. I was just wondering, matrix is also the most recent addition. So it's kind of, I would understand why it wouldn't, you wouldn't have exposure to it. So, yeah, so I'm going to switch from the hands on materials. Before that, if you have some questions you can ask what I'm going to on the hands on tools that basic pipeline usage of my variables options or agent definitions. And also I'm going to show some complex stages like inner and parallel stages, and also some steps and secrets examples. I also defined a hell of a repository in the below link so you can always visit this repository and CD, all included pipeline tutorial in that repository so you can always reference that. So I, yeah, there is one question from the channel on about what the motivations are for using YAML. Before we move on to the demos just what are the benefits and motivation for using YAML as opposed to just declarative pipeline as it exists. Yeah, of course, like, I mean, I just like the definition because you just look. How can I say less. And also like YAML definitions are really widely used in the develops world so I believe it will be much more easier for everyone to understand the definitions because that this index has its own decorative format. But of course it is optional. So I just love YAML. So familiarity you're saying it, at least in one sense it's familiar familiarity for people that are already in this world, using YAML. Yeah, definitely. I mean, any application that do not support YAML in the workforce. Apparently just Jenkins to there you go. Not only Jenkins. We use Kotlin and other things in other ACI platforms. But actually it's a good time to launch the poll because we would like to get feedback from audience about what languages would you prefer to use. And yeah, while the poll runs, we can actually start switching to demos part. Yeah. Again, if you have questions, please don't hesitate to ask him some point a and yep, maybe we could answer a couple of more before we switch to demos. Okay, so the first one is about contributing is that the open source is the plugin open source so that people can contribute to the project. If so, how to do that. Here, of course, I'm sorry. Like, of course, this is like open source plugins so everyone can easily contribute on it. Also, you can create issues on the pipeline as YAML plugin GitHub page. So every feedback is appreciated. Also, we will be so glad if you can also provide your usage feedbacks because we tried to keep it as much as useful for everyone. So if you have any questions, please feel free to ask your questions or create issues or contribute. And there was one other issue and it's a little bit of a detailed question but when you go to replay a build when you're using the YAML pipeline. Does it show YAML or does it show the transform declarative groovy version of the pipeline. Wow, that's a good question. I never checked that. We haven't checked. Okay, good. So that's a feature to go take a look at. All right. I need to note it. I'll keep track for you. Go ahead. Okay. Thank you very much. Okay, so now I'm going to switch to hands-on experience. Sorry, tutorials. I just started an Jenkins instance and I also installed the pipeline YAML plugin into my Jenkins itself. So what I'm going to show today, I'm going to start using the, sorry, let's say tutorial one, and I'm going to start using with the pipeline job. So after a few examples, I'm going to show or demonstrate how to, you can just define in the multiple branch. So that will be easy. Okay, so when you install the plugin and when you create your pipeline job, you will see that there's a definition. Of course, you can use the pipeline script or script from SEM as usual, but to other options, which is pipeline is YAML and the other one is pipeline is YAML from SEM. So pipeline is YAML from SEM is similar to what we had before pipeline script from SEM. So you can define your any type of SEM repository and you can just provide the path of the Jenkins file that YAML and you can use it. But for the easiness of the usage, I'm going to use a C clip panel for today's tutorial. Just I want to start with some simple definition of checking out the code from the repository and to maybe some steps. So what we do is that we just define our pipeline. Then we use this YAML syntax. Then we need to define, of course, agent. Sorry, for that dimension. So it's a quite important. If you visit the web page of the plugin, you will see one example of each directive in the lead page. But also you can just easily go to the links and see all the different variations of the implementations. For example, if you want to go to, if you want to see the other implementations of agent definitions, you can easily go to the link. And you can check the different variations of agent definition. So all these files are in stored in the test resources directly. So also, for example, I'm going to demonstrate the environment options and other different types. So let's do together. So I'm going to use this agent any definition. So it is similar to the directive syntax, which we define agent as any. So I'm going to use any definition. As soon as I defined my agent, I'm going to define my stages. So what I'm going to do, I'm just going to use stages key. And then I'm going to define my stage. Let's say check out. So for the stages, also, as I said, you can just check here and see all the different kinds of stage definitions. I'm going to implement every possible scenario of these stages. So you can easily find, I think, what you're looking for. So let's use the pipeline syntax, which I want, which I mentioned before. So using the current steps is possible in the pipeline as young. So what I'm going to do, I'm going to find the checkout comment. And I'm going to. Okay. So I'm going to check out my code. Yeah, I'm going to check the master everything is fine. So what I'm going to do is that I'm going to copy this step. Then I'm going to define as a step under here. So what I'm going to do is that I need to define my steps. The definition are used as arrays. So you can easily define every step by defining as it's YAML array. So I define my steps and just I wrote my git checkout step in here. So I'm going to apply and I'm going to run it. So the expected behavior is to check out the proposal. Let's run it. Check the console. Nice success. So we just did our first checkout with the pipeline as young. Let's start to jump in. Usually in declarative the checkout just is part of the stage. Is that, is that not the case in general for this or. Yeah, excuse me the way we know that's only in multi branch pipelines my bad. Continue. I'm going to show that. No. So I'm going to define my second stage will be something. I want to build my code. So I'm going to define my step again. And I'm going to get an SH main one clean install. Also, SH another step defined in. So as you can see, you can use the early step here. So let's run. Of course. So that's a good example. So what I need, I need to get the tool may one. So before the presentation, I prepared my. May one to installation. So I need to check the name of it. So let's see. Yeah, I have a main one installation here called default. So what I'm going to do is that is the decorative pipeline. I need to get my. To as defined in that. So what I'm going to do is that I'm going to use tools and the tool section I can easily define my tool section. So, but before that I want to also show something. So if you're not sure about the declaration of the tool, you can just easily go to the pipeline syntax helper, and you can just get your main one. Yeah, that's it main one and default. So what we are going to do we are going to convert it into the demo format. So it should work. So it's been successfully so it was just an hello application. Okay, so our next is the next example I can demonstrate the inner stages. So what we can do is that normally we just divide the stages into some sub stages. So what we can do is that maybe build and test or lease a let's say may run. So I'm going to live this section and I'm going to demonstrate how we are going to define sub stages in our stage. So especially it is very similar to decorative usage and also as I mentioned before you can easily see all the usages in here so this is the example for using inner stages. So under my stage definition I also again defined stages and after that I'm going to define my other sub sub stage, which will be built. Then I'm going to write this secret or step as a secret. So also you can always use the similar secret tech, which is similar in the decorative pipeline so I can just easily write me when clean compile. And also I would like to show one example about this. So if you want to write some more complicated steps or secrets. What you can do is that you can use this secret multiline when you can just easily write your glue secrets here. So that's another way of usage. So, okay, I will compile my code and then I'm going to define another stage, which will be test. I'm going to use it as a step stage test. So let's go for it. When you check the pipeline flow, of course you cannot see but if you are using the blue ocean playing you can easily see that this built and test is a sub status of the name. Let me check my examples. Okay, so can you make it the font just a little larger just do a command plus something to just a tiny bit. Yeah, cool. That's great. Just a little bit larger. Great. Thanks. Okay. Thank you. I want to demonstrate the options or the maybe the environment definitions in the pipeline decorative so what we can do is that of course we can just set some options for our jobs, which also can be find here in the decorative director generator so what I'm going to do I just want to set this job is disabled concurrent builds so you can use any definitions here so I'm going to just going to demonstrate this one which will be a simple so I click and I generated my decorative so what we need to do is to convert this into formal format so I'm just copying this function here then I'm going to define here options disabled content fields so you can always define other options under the options key with your list and also you can find the other options definitions. Here. So yeah, I just want to disable the content bills so I'm going to apply it. Yeah, it's quite. So it's running everything seems fine so I'm going to check if it is set or not. And yes, so it is not allowed to run concurrent bills. Okay, that's cool. So what I can do I can just get some maybe credentials and pass it to my maven command or something else so like you can just think about as deployment to somewhere else so my examples maybe you won't make sense now but it is all about showing the usage so I need to Before the presentation. So before the presentation, I just created my credentials here so so you can go to my credentials. So it's in that you defined some credentials or yes or you have some credentials to use so yeah my custom credentials is just basic username and password credentials so I'm going to demonstrate how to use it. Of course anytime we can just get the help from the pipeline syntax. So oops. Okay, so what I'm going to do is that I'm going to use with cadential step to use or get the credentials from the credentials store so I'm going to use a name password and yeah this potential so journey. So the tricky part is here that you need to use this part between the commas so what I'm going to do is that I just want to use my credentials so here with credentials, I will pass it. Yep, and then I'm going to pass this credentials as usual to my maven comments so I know there's no need for that but I just want to demonstrate it. So assume that you're passing some username and password parameters for compiling or testing or deploying your artifact into somewhere else. So let's run it again. Okay, let me check. Oh, sorry, my bad. I forgot to define steps so as you will remember the in the decorative syntax of pipeline. When you use the with cadential step you need to open a code block so for that to be implemented we need to write here circuit and we need to define our SH commands here so and clean compile username. I'm just going to use the username. Okay, so, so you will see that this parameter is passed as a secret into my comments. Also, another similar step which we can use almost the use is that with me section so what I can do is that I can just easily use with me so to be sure I'm going to use the in mind that I will definition so maybe I can do something like that. Okay, so what I'm going to do I'm just going to take this part is again, and I'm going to define it in my pipeline. So with EMV. Again, I need to define its own scripts. Part to make it long so the question there for you to those is that need to be script or can it just be steps. It needs to be secret because, as I remember, in this step definitions, the code block accepts also really syntax or the language so that's why I implemented as a secret but of course we can always change the step but I believe secrets will make more sense, which I thought. Okay. So, okay, I'm going to run it. Let's see. I couldn't resolve. Okay. We can just. Okay, so for next to you, I can show you the maybe parameters part or let's define with one. Yeah. So, just jump in here for just a second. I've, we would want to at least one of the question. Related to the, you're using the script, the declarative directive generator and the, the snippet generator is, is there some plan to make this generate yaml as well or is, is that yes. There's a list somewhere at least is something you'd like to do. Yeah, definitely. I'm planning to do that, but it's just every blue part for me. I don't know how to generate these so probably it will be just the next, next, next releases. Sure. I don't know one, but of course it will be very useful because I know that's this kind of converging is not very useful. Okay. Thanks. So, okay, I'm just going to move past this. I don't want to get us. Okay, so I just want to demonstrate on the also the run definitions. So let's go to the old. And you can see that we can always define the one definitions in the under the stage like is in the decorative pipeline. So I just want to use it in here. Let's make another stage. Yeah, so let's do deploy. And also I would like to do something steps. Maybe deploy somewhere. So I'm going to translate it. Okay, so now when I run it, this will be skipped because we are not using the multi branch pipeline, but this is a demonstration how to use the plan conditions in the pipeline itself but I'm going to also demonstrate how to define this in the multi branch pipeline. So yeah, you will see that this stage deploy is skip to the run condition. So that's another usage for it. And also we can just define some other environment variables, which is quite similar to other activity definitions, so I'm going to define some environment. And I will say that my server and so I just want to like, okay, so is still we didn't see the change on the deploy section, but we are going to see it in a minute. So what I'm going to do I'm going to commit this, or maybe I can just use the, the one that I already defined in the repository so the total repository there's a pipeline directly so there is two different ginkgo file emails. So one of them is about a very similar usage of the things that I showed before you can just reference this usages when you always want to see some examples. And also, there is another Jenkins file definition in the multi branch path, which I want to demonstrate it so as you said before so in this email file is you see we don't have any good checkout sections because multi branch pipeline will do it itself. So in the multi branch pipeline we are going to use this run condition and we will see that this deploy stage will be run. So, I just want to get my repository. If I need to find a new job, let's say, told you to, it will be multi branch up yet. Yeah, this goes all the branches. So what I'm going to do is that I'm going to say to select the ginkgo file as well and I'm going to provide the path of the Jenkins email file. So it will be pipelines, multi branch Jenkins file. I'm going to save it. So it's going to find the branches. Yes, we found the file. So when you go back to a job you can see that master is already start working. You'll see the box at the end of this job. We are also going to see the deploy section is running. So it is all about the run condition. So yes, as we can see from here. So the also deploy section is working. So maybe just one, just one last example. So the usage is also same in the pipeline itself so you can just easily configure your pipeline from the pipeline as you'll form SCM which is really similar to multi branch. So you can use it. That would get you the automatic checkout and some of the other behaviors that you get there right. Yeah, definitely. So one last thing I want to show that is the converter part so you can just go to the pipeline syntax and you will see the pipeline is converted. So as I said, currently it is working one direction so it was pipeline into the decorative format so if you just paste your definition you will get the decorative definition of your pipeline. So if you are not sure of the some definitions in your name or you can just easily check it from here and see if it's going to make sense or not. And also after defining your take 30 or sorry, after converting your pipeline you can just validate it and very detailed response so it's valid. So this is just for like the running errors before running the pipeline so in the future implementations I'm going to implement the bidirectional way of the conversion. So, very cool, very cool. I think I demonstrated lots of things I mentioned. As I said, you can always find more and more and more details about the usage in the pipeline. You can also find the plugin web page. And also I'm going to keep this positive also for reference so you can just easily check the same definitions for your requirements. So that's all from my site. Thank you for listening to me. And also I'm happy to answer your questions. You've got quite a number of them. So would you like to drive the Q&A? I can at least do some of that. Let's see here. No, go ahead, keep it for now. We might need to show some things. If you want to switch back to the slides, if you have links there for the example. Yeah, that'd be great to have that up there while we talk for a minute. So there was a question first off, I'm sure everyone's very excited about this. When will this plugin be ready for production? Thank you. So we are working hard for that. We are going to do some maybe major changes in the next weeks, but I believe also it depends on the Jenkins community itself. It will be online maybe one month or two months. I don't know, but we will try to do it as much as fast. Basically, this is a volunteer organization, right? So it depends on how much participation we get, right? Yeah, yeah. And also like we will be very grateful if someone also can help us contributing to the plugin and applying changes with us. So that will be also great. Okay. The other question, at least one of the other question was, let's see, is there any performance difference for using YAML that you've been able to make sure? I haven't experienced any problems about the performance itself, but I didn't do any performance tests. So I believe we won't have any performance issues because the conversion is very quite simple. So it is just about passing YAML and converting into decorative. But it's a nice question. I will do some performance checks and try to find out some values. Okay. So, okay, good. What about, so you showed the agent NE there. I'm assuming also that Docker agents and such are supported, whatever the usual agent blocks are. Yeah, definitely. Yeah, also let me show it please Ian. So if you check the page of the plugin, you will see that there are different definitions of agents. So in the current release, we have the agent Decker and Decker file implementations. So you can just easily define your Decker using the keys necessary for defining this Decker image usage. And also you can just use the Decker file also. And also other default users like label, node and none is also possible. There was one related question in the list about Kubernetes plugin, because the plugin is famous for its complex configuration. So why it would be supported. Let's add it into the plant feature stuff. Yeah. Okay. So if you have another thing to add for the feedback. Cool. I think that Kubernetes plugin will work as is if you define it as cloud configuration right now. So the only problem is, is more complicated definition when you define container and basically put YAML configuration right inside configuration. So it would be YAML in YAML. Yeah, I don't think that the current syntax parts would support it correctly. Well, you can put YAML string that has a lot of limitations. Yeah, let's see. I don't know how to internet, but I will check. Okay. Does this, does this, does this the YAML pipelines work with configuration as code. Yes. So if you install the pipeline as YAML plugin, you can easily use it, but I need to check if there's a special definition. I'm not so much familiar with the configuration as code, but I will check definitely. Okay, so we need to look at that. So, yeah, right now it will work well because pipeline is YAML basically has no global configuration. So you install the plugin and it just works. And you can benefit from our features. For example, you can define secrets, you can define agents, clouds, etc. using this code and just consume them in YAML. So definitely there is a lot of code reasons between these features and maybe eventually we will be able to put YAML job configurations right inside jcask. So right now it supports the job they say but in principle we could put YAML. But yeah, it's an implementation detail. So, right. Yeah, because so you have, you have job DSL in you can have job DSL inside of there and then define a pipeline inside the job DSL. Right. Yes, which is a little, it's a long way around to it, but that's, that's what yellow paste the link to the chat to what I'm talking about. So there is a way to create seed jobs and the defined jobs basically right inside jcask configuration. Right. And yeah, later when we have pipeline is YAML, it would be great to have support. So that we directly put YAMLs there. So let's see here underneath the covers though, do you have a, is there a schema that's like pre-generated for the YAML or that someone could go and pull out or is that something that we're still working on? The schema will be available after probably defining the IntelliJ plugin. So I'm just planning to define a schema for the pipeline definition and also use it in the IntelliJ and also use it in the Jenkins itself. Okay, so it's still in progress. Yeah, definitely. Let's see. Someone that was asking about whether or not this solves problems with the, with escaping characters and quotes. And I would assume that's not the case. But it's a unit to be a little bit careful about that. So maybe I can show something. So, okay, so let me just give some parts. If you find a good example for that, just a second. Okay. Maybe I can demonstrate something. Okay, so you need to use double quotes if you are using some steps with special YAML syntax like here, like semicolon. So when using these, you need to use this link double quotes at the beginning and at the end. So that's the only escape that maybe you need to use. In the other parts, you can just also use like double quotes if you want to define, but also you can just leave them as alone. But this is the only situation that I experienced. So if you experience any problems with escaping characters, please definitely open an issue and let us check it. Okay. One of the advantages of YAML format is basically you're not limited only to quotes because you have an opportunity to use multi-line syntax. Yeah, to work around using too many quotes in some cases. Like for example here in the steps definitions, you can just use this multi-line definition like here. Oh, neat. Okay. Very cool. That's all the questions that I see on the list in that were that we haven't already answered. Yeah, there are a few questions which we could still ask. Were they were they in the chat as opposed to the Q&A? Questions and answers. So for example, one of the questions is about can we do this and YAML definitions coexist in the same folder? Oh, right. Sorry, I was asking asked them for a clarification. That was a little unclear about what that was. Basically, whether it would be possible to put Jenkins file and YAML definition in the same directory. I don't think it will cause any problems. So yeah, why not? It is just two files. And I guess one of the other questions was what are the, how does this work with shared libraries? Oh, that's very good question. So yeah, maybe I can just show the example because we may need to define library. But so, okay, here's the library usage. So after you define your library in the Jenkins configuration, you can just easily use this library definition in here. And also you can also check the other definitions here, but the usage is very simple just define your library in the beginning of the pipeline. And also the definition string is very similar or very exactly similar to what we have in the declarative pipeline. So you can also easily define two libraries, something else. So it's all up to you. And I noticed that you have the script directive there as well. And that's so that we can call out to so that you end up using the groovy syntax. Yeah, definitely. Right. Okay. So like, maybe I can show it from here this in a moment. So there's a test for it. Yeah. So it is, oops. You click job. Yeah. Not the resources. So, Did you want the resources to show it? No, no, no. Okay, cool. Yeah, I don't waste time for that. But Yeah, as you said, you can just use your custom steps in the secret secret definition steps. Okay. And their question, what about to variable interpolation doing dollar sign, curly, curly brackets, etc. That works fine, right? Like, as I showed in the example, so you can just easily use this dollar sign with bracelets, so you can just use these variables, which will define the environment or in the input section. So you can easily use this. Okay, okay. Let's see. Does that make sense? Okay. Yeah. Now, if there were problems in the, in terms of the interpolation split that this wouldn't fix those though, right? That it was what someone's kind of asking about. Uh, fix what? It's probably worth. This is the like if the if the username there had a dollar sign in it, for example, or something like that where there's a. Yeah, that's right. There's this. Those are, I think you'd end up most likely running into the same issues right where you would as you would in groovy. Yeah, definitely. So, especially it will, it will throw the glue exceptions because as I said, like in the conversion party just courses into that. So you will explain the same problem. All right. So this doesn't, this doesn't fix some of, if someone's having a difficulty stating something in declarative, this won't necessarily make that, that better. It won't fix that problem for them. No, no. Okay, that's fine. That's fine. Let's see here. One question you had in the beginning of meetup is about the replay feature. I did ask about that already. We that it's not, we hadn't actually checked it yet, but I put on the list to, to, to that we would definitely want to want to try it out. Actually, can you do it right now? Can you just try taking one of the things that you ran and just do a do a rebuild on it. So take one of the jobs down the left, click on the number, and then do a replay. Like we get declarative. Yeah, we get to declare it. What would you prefer? Well, if someone wrote something in YAML, they probably want to see. Yeah, okay. That might be a little bit harder to do, but it's an interesting feature. Yeah, let's see. Okay. I have a couple of questions with that report the back on Sunday, because I hit regression and Jenkins fellow runner when I was implemented pipeline is YAML support. So there might be some issues with extension points between the replay and pipeline is YAML. It's yet to be seen. Right. Okay. Well, I don't see any further questions that we can answer. I assume you'll have the link to the slides when we post this. Yeah. Okay. Great. Well, I can hand this back to you for, for closing this out. I'm not sure we're. Okay. So, yeah, I stop the show. So, thanks to everyone who joined the meetup again after the recording, you're welcome to stay online so we can discuss more questions and topics of the record. And if you want to share anything with the speaker or the organizers, we ask you to fill in the feedback form. I will post the entity, or you can just stay online so that we keep talking about it. Okay. Thanks to you for the great presentation. Personally, I'm looking forward to see this plugin in production as well. Well, just a big fun of group video set, but at the same time, I think that having a YAML option is a great addition to the pipeline ecosystem and to the Jenkins project in general. So thanks a lot for your hard work on this topic. Thanks. I really appreciate any feedback. So try out the plugin. If you hit something submit the issues, join the charts and share the feedback because any contributions matter and good feedback is also a great addition to the project. Yes, also it is important for us before going to the production version or like the release version because we need to. We want to cover as much as possible from the community feedbacks. So please feel free to forward some feedback. Yeah. Thanks all, and see you at the next meetup. We are planning to announce in the top to the beginning of almost later this week. So stay tuned for the announcements. And of course, the ideas will be published soon. Thank you. Bye bye.