 Hello, everyone. Welcome to a Jenkins online meetup. I'm Liam Newman. I'll be your host for today. Today, we'll be talking about Jenkins configuration as code. It's a new project being hosted by Prachma, sponsored by Evelino Vilkos, sorry, and Nikolai Duluth. And they'll be telling us all about it today. Evelino, why don't you take it away? Oh, wait, sorry, my bad. We'll be doing questions on the IRC channel, the Jenkins IRC channel, hashtag Jenkins. Go over there if you have any questions, and I will field them and pass them along. All right, take it away. Thank you. Hi, everyone. So today, as Liam mentioned, we'll talk about Jenkins configuration as code. We're going to tell you why we do it, how we do it, what it exactly is, and most importantly, how you can get involved if you're interested in that. But let me introduce myself and then Nikola, who will present together with me today. As Liam mentioned, my name is Evelino Vilkos and I work as IT consultant at Prachma. I was a software developer before for six years at Ericsson, but I decided to join the continuous integration and continuous delivery. My daily work, I mostly work with Git, Docker, and my most important task is Jenkins as code when possible. Nikola? Yes. So I'm Nikola Delov. I'm working at CloudBiz as part of the CTO office. I'm a Jenkins contributor for a few years now and also a Docker captain, so involved in various Docker plugins. And as part of the job, I was involved in investigating some as code principle for setting up Jenkins, so my presence here. And as I'm also a conference organizer in my local city, a video organizer, and also doing some videos. So you're welcome to join me on YouTube. But anyway, let's focus on config as code for today. Thank you, Nikola. So those of you who are ever trying to start up their own Django that it can be installed in a very different way through native system packages using Docker can be run standalone by any machine that has Java installed. But it doesn't matter how you run it, most of the time you have to manually configure it. So your family are probably with that kind of page. It may not be very readable, but but yeah, this page can become much, much, much longer and this is only a small start of a new Jenkins instance. We have to go through the pain of feeling all the information. And we don't always like that. I can imagine there are situations that maybe it's comfortable and easy, especially if you're in most of the time, I'm going to risk the statement that we don't like that. So we would like to get rid of that part. So the question is how do we solve it and we will solve it. It's how we will refer to Jenkins configuration as code during the presentation. And in general, we use this this short version quite often. Do you usually pronounce that? Do you say is there a pronunciation for that? Or is that just just how you write it? Oh, that's a good challenge. J.Cask, maybe. J.Cask. Yeah, right. Yeah. Sounds good. Sounds good. And it was continued. There was a lot of discussions about how to abbreviate it. And I think like most of us are happy with J.Cask. But yeah, before I dive into J.Cask, let me explain how it started. It will be a very short story. So it's idea that we want to make it easier for our customers to spin up their Jenkins instance to make it more safe, more reliable and easy to reproduce or restore in case any failure. So we started this Jenkins code reference project that is successfully rolled out in a number of our customers. And Pragma itself is using this project for our own Jenkins. But during that and with our customers, we discovered that it has some pains. So it requires everyone who wanted to use it to be all in, to use a very specific Docker solution. It was complicated and it has complicated and time consuming redeployment process. And I have those quotation marks because it's not really very complicated. And the time is a matter of minutes. But in a modern software development world, we minutes are too many times it's becoming complicated. Most importantly, we had what mixed with how. So we were relying on the solution provided by Jenkins, allowing you to put groovy scripts in a specific folder. And the scripts would be run when Jenkins starts up. But we had configuration, the groovy scripts mixed with the actual configuration of specific Jenkins instance. And we've decided that we don't like it a lot and we need to have the same functionality, but will be easier to maintain, easier to use with Jenkins as code reference, which I still like and feel very comfortable using that. We weren't happy with forcing users to fork repository to actually use our product. That's how we came up with the idea of creating a plugin that you can very easily download and will not repeat with it with Jenkins as code reference. So, JCASC is actually Jenkins plugin that is available via this link on GitHub. And I'm assuming we'll have a way to share this presentation in some way. So, all the links you can see here, you should be able to get a PDF presentation, right? We can share the presentation afterwards and then also I can put it into the description and add these links in so that they're available afterwards. Yeah. Perfect. So, we hope this Jenkins configuration as code plugin will be the configuration as code solution for Jenkins. And there is a JEP, Jenkins enhancement proposal document level that is still in the state where you can comment and discuss proposed solutions and ideas. So, if you're interested in the future of the project and you have ideas, please go through that. We mentioned we had Jenkins as code reference project and I mentioned it's pain, but I don't want this plugin to be only a solution for my issues. So, we want to follow the process of creating JEP and having input also from other users. You're basically describing how most plugins probably started. Someone had a problem they wanted to solve for themselves and then made it a little more general and then put it out into the open. In the past, the project would just sort of organically have one person running that plugin and they would sort of own the feature set and all of that all at once. And just for people that aren't familiar with it, the Jenkins enhancement proposal is a new sort of process that we've put in place in the project that lets us sort of gain a consensus in the community and have that overarching design and direction of larger enhancements be something that we all sort of talk about together and move forward together. And so, it's great that you've started this as a JEP as well because it means that everyone can jump in and give design feedback and point out more things that need to be done or sort of drive the direction of things. Yeah, and the more people involved in the early stage, the more chances for success in the future. So, we started at Pragma, me and a couple of my colleagues working on some solution and then we got in touch with Koske and Nicola and Oleg and they are also working on a similar solution and the ideas we have and the requirements we have are very much aligned. So, we decided to work together, which meant it was not exactly how we at the beginning but, well, we're happy that we were able to change the direction at the very beginning. So, for some time, it was Pragma's and CloudBiz effort working on that plugin but a couple of Alpha releases were already available out there and we've already got some external contributors and I have no idea how they found out about the project but I'm very happy they did. So, we have Kirill, Dev and a couple of other guys that are contributing via creating issues, via providing documentation or even implementation. So, thank you very much guys and whoever's interested, yeah, to the GitHub repository where we use, for now, we mostly use GitHub issues to discuss and track the progress. So, I wanted to say on that subject, you should ask them because it would be interesting to know how they found you. I mean, some people probably are just subscribed to the Jenkins CI GitHub or something like that but it'd be interesting to know how they picked this up. I mean, this is obviously really an interesting area for someone running Jenkins in general but maybe we can ask them afterwards. Yeah, I mean, so what I wanted to say when I said that I have no idea how they found out is that it's not like we had to change people. The project seems a huge interest and I'm just happy that people that are not pragma-related or CloudBiz-related are willing to spend their time and help us to create a solution that, yeah, solve issues of all of us, not as I said, only things that I experienced I don't like. Great. Yeah, so once again, thank you guys and, yeah, we want to be accountable so you don't have to be a hacker or a very experienced Jenkins user to start using Jenkins configuration as code. So in general, the idea is that you have to write to prepare a Jenkins YAML file and store it on your local disk, store it in your repository, where, how we maintain it, that's another thing. But a very simple idea, we have YAML file that is being given to Jenkins and whatever you have under-managed Jenkins should be configured automatically during startup or when Jenkins is working, which I will show during a very short demo. So Configure Global Security Page, Credentials, Tool Configuration, Plugins, those are sections that we want Jenkins configuration as code plug-in handle. The main benefits that I see is safety, security and traceability that will be available if you decide to configure it in the control system. The speed, and I have different kinds of speeds in mind when I think about speed, so it should be very easy to restart Jenkins in case of, I don't know, a disk failure where you have to move it to another machine or a few containers or if for some reason you need to start because you have another project, another company already working Jenkins Configuration as code, you simply copy Jenkins YAML file and change things you want to change and then you have your new Jenkins working. So it should be easy to use and easy to reuse in case you need to scale. Right, so recoverability, so when you think of recoverability and then also reproducibility, you get to spin up another one whenever you need it. Yeah, another point you mentioned is that we don't make any assumption on where this YAML file is stored. So it can be provided from a SCM repository or whatever code management system you are using, maybe adopting Jeff Puppet or writing by hand if you really want to, but we can just embrace all practice in terms of operations. There is no restriction to only support one of those tools. That's really open to lots of integrations for various use cases. Cool. Yeah, exactly. So we have this great ideas about this great product, but of course there are some challenges and for now you can see a slide with the summary of those challenges, but we have one of those challenges, so I will just move on. Human readable config files. So I already mentioned that we will use YAML. We had a discussion if it wasn't up. But I find YAML very easy to write. It doesn't matter what kind of keyboard you have and I have this issue with switching between Danish keyboard and English keyboard and I still can't produce some of the brackets. So I'm very happy with YAML. That's a really interesting point. I didn't really think of that in terms of English centric keyboarding and brackets. Yeah, as I said, as to some characters, I simply can't produce on my keyboard, so I just have to find them on the internet and copy and paste. And if you need to use three keys to produce a bracket, then you're hating. So that's how we ended up with YAML. That is pretty bad. The fact that we don't need to use different kinds of brackets is not the only advantage of YAML. It's very easy to read and I find probably even for people that are not software developers, it's not a rocket science, it's commentable and it's not language centric. So it's not like you know a specific programming language and it gives you the advantage. So it's what we decided to go with because of how easy to use it. And of course, also you're talking about settings, right? And so the fact that it's sort of a static statement of what's in there, you don't tend to need to do four loops and stuff like that for this kind of thing. It's a very easy structure. Right, right. The main idea here is if you want to do some logic in these files then you can just plug your favorite stomp latency just before checking this passing this file. Sure, sure. We don't want to make such decision as a prerequisite to adopt a configuration as code. Yeah. So another, like the biggest challenge, no hands-on keyboard, no click on UI should be possible to get a fully working Jenkins master without those. And of course, at some point you have to click at some point. You have to use keyboard at least to prepare the Jenkins YAML file. But when the basic stuff is ready, you should be able to easily automate it. And we mentioned risk stability is a failure. So once you prepare your configuration and automation scripts, again, the plugin does not care about how you start up your Jenkins. So it's not like we will provide you a way to fully start without clicking anywhere. You can use Docker. You can use another solution. And we will talk about some places where you can find some help regarding that. But in general, it's only about configuring Jenkins. But once the configuration file is ready, you should be able to avoid UI if you don't want it. Also very important thing, if not all, of the plugins by default. So the first idea, I mentioned that we got in touch with CloudBiz and they had a similar goal, maybe a little bit different idea. So I'm up with that. The first idea I had was like, yeah, right, support for every plugin. And then realize that we have more than a thousand and a half plugins already available. And even if not all of them are configurable in this managed Jenkins globalization, it would be a lot of code to write. So smart solution is where we don't need to write Glucote for every supported plugin. And we hope to support most of the plugin, at least the ones that are written following some conventions, to support them out of the box. Of course, it's not the case right now. We still need some dedicated solution for specific plugins. And I think we'll talk about this later. But nevertheless, we believe that this plugin, Jenkins configuration is called plugin without an extra effort. I mean, you already know that without an extra effort, a number of plugins are already supported. And if there is a plugin that is not currently supported, we can either create some solution on Jenkins configuration as code plugin site or we can submit the solution for the plugin. So it depends on specific case, but we have different ways to solve potential issues. Also, what we want to achieve and make available for you is to generate documentation and validation tools. So again, we don't have to write everything manually. And so you don't need to be a Jenkins expert to prepare Jenkins YAML file because documentation will be available. And there are ways to how job DSL plugin does it. When you use job DSL plugin, you can have access to an API viewer on your local Jenkins instance that will reflect your installation. So the plugins we have installed will be listed there and support for this plugin and how you can use job DSL for those. So it will be similar for us. You will have a full documentation based on your Jenkins instance when you use Jenkins configuration as code support plugin. Sorry. So yeah, we have ideas. We have challenges and the link to GitHub repository with the plugin was already mentioned in one of the previous slides, but here it is again. And there are two very, very interesting and important markdown files in this repository. One of the files is implementation detail description. And we also have guide for plugin developers. I mentioned that plugins that follow some rules will be supported with the box. And the plugins MD file describe what we need in a plugin to support it with Jenkins configuration as code. So before we head on just for a second, I'm just going to hop in here. For those who arrived after we started, we're taking questions on IRC. If anyone has any questions, go over to the Jenkins channel on IRC and you can ask them there. And actually there was someone who was asking whether or not, I know you guys are still in process on a bunch of features that you'll talk about that you guys are working on later. But can you create jobs as part of the Jenkins configuration as code? Is that something that would be handled by another? Yes, the actual job DSL syntax that we who use job DSL plugin already know will be supported by the why the plugin and I actually can show you a snippet of YAML that I used to create some initial jobs in my demo instance. So okay, cool. We'll get to that in a minute then. Great. And also there was another question someone asked about adding an init.groovy. Is that also still supported? Can you create that as part of the configuration or is that on the list somewhere? So you broke up for me for a moment. Oh, sorry. Sorry, so my question was whether you support creating an init.groovy, setting up an init.groovy as part of the the YAML file. Right, I think, in general speaking, it's about iterating external files into the Jenkins setup. That's not something we have considered so far. I don't see any reason we can't. I'm coming from an IRC channel. Yeah. Yeah, okay. So yeah, we'll definitely go through whatever was mentioned there after and we can have a discussion about creating some new features. But as Nicola said, not the case for now, but why not get a feature. Yeah. So actually that's the time where Nicola is taking over. So I will stop sharing this your screen, Nicola, right? So just have to. Yeah, you just have to hijack the sharing, I guess. Okay. So and just if it looks like Oleg Anashev is also listening in here and he was saying that it looks like and its scripts actually do work like a charm, he said. Yeah, actually I wanted to comment because yeah, in the script say actually supported in Jenkins maybe for 10 years or so from very beginning. So you can set up Groovy Hooks and these Groovy Hooks work well together with configuration escort plugin now. So the order that firstly configuration escort plugin runs. And then if you need to do something else, you still can use old style mechanism to do configuration escort if needed. And I guess that, for example, the configuration escort reference within the reference in the beginning also uses Groovy Hooks, right? Is that right? Yes, technically you can use both solutions if you want. But of course it requires some attention because you may cause collision. Okay. So there's a little bit of caution there, but it looks like it should work. Right. Yes. Okay. So let's talk a bit about the hood, how we implement this stuff and to explain this, I will try to explain the mechanism starting from a YAML file and getting Jenkins master configured. So just FYI everyone, this is Nicola. Mentioned earlier in the presentation just making sure everyone knows. Right. So when I joined the configuration escort effort as part of working at CloudBiz, what we had in mind was clearly to avoid writing dedicated code per plugin. And so this was perfect complement for the effort made by Pragma. So we just joined force on this topic. And so what I want to introduce here is how we can pass YAML file like the one I'm just showing here to get Jenkins master configured without getting anything changed on Jenkins core or any of the plugins that we have installed. So the first point for the parser is to be able to identify the target components that we are trying to configure. So in this YAML file, we have the Jenkins root element and we also have a major root element. So in terms of plugin APIs, we have a dedicated API for this root element configurator. And this guy comes with some default implementation. As you can guess, we provide one for the Jenkins root instance. We also have configurators for the BIOS global configurations that you have for all your plugin descriptors. So if you remember Jenkins UI, they are categorized in terms of tool installations or security or things like that. So this information is already available in Jenkins API. So we are using it to provide some top level tools and security side by side with Jenkins. And for all the remaining configurators, we just use a simple name like the mailer plugin for example, come with this mailer root element. And as I explained, we come with some default mechanisms that we expect to cover most plugins. But there is always some corner keys. And so typically we have one with a credentials plugin. So we created as a proof of concept a credential root configurator that introduces credentials root element and allow us to just plug some specific adapter code. So one can configure credentials despite the plugin internal design is way more complex at what we want to expose or support with configuration as well. So based on this mechanism, we have identified the target component in Jenkins for every root element in the YAML file. Now the second flavor from this Jenkins root object is what we call an attribute. So you can just think in terms of Java code like Java being properties. That's exactly the same thing. So here we have the security realm. We define some abstraction here as well. An attribute has just name and target type. It can be a collection of things, just a single element. And we need some way to set a value. So there is no requirement to have a Java being setter. That can be something very abstract with a custom implementation. What I'm thinking here is anything about doing some lookup to drag a singleton or whatever adapter code you want to write. So the external API is just to say I have a name, I have a type and I want to set the value. The generic mechanism is just to rely on Java being setters or the tab on code trick door for new objective one to create. So following this symbol, we have the set security realm that allow us to set this attribute. And the parameter, the target type, actually is an extension point which means that security realm is an abstract class. So the next step for configuration as code is to understand which specific implementation we want to set up. And the only input we have is this LDAPString. So what we do here as we know the type that we want to create is we have a list of candidates based on the install plugin on the specific Jenkins master. So some components already are using the symbol annotation. So we already have a name for them, which used to be a very short one, human-friendly name. And for other plugins, some legacy ones or maybe some of them just didn't yet adopted this practice, we rely on some pattern discovery, something that Java developer used to do when they implement an API is that they use this API name as suffix for the class name. So, for example, the LDAP security realm, we can guess what I like to call a natural name as LDAP by just removing the extension class name. And based on this, we can discover that the requested LDAP implementation is just the LDAP security realm from the LDAP plugin. So this and the plugin does this automatically? Exactly. There is no single change made in the LDAP plugin. Interesting. And if, let's say, the Active Directory plugin maintainer dislikes this long name as Active Directory and would like to just have AD, it can just improve its plugin by adding a new symbol annotation under the class name. So you have symbols here. But we have worker runs to avoid. What we want to avoid here is to enforce people to use fully qualified class name. For those of you who are being adopting pipeline at the early beginnings, there were many places where you had to use some dollar class and the fully qualified class name of your target component which resulted in ugly scripts. And thanks to this symbol annotation, we now have a very simple way to just express which component we want to use. And so we have introduced some conventions to guess such a name for every component in Jenkins. And so the guessing part is the point there is to speed adoptions. With thousands of plugins, you could actually go file PRs against these against other plugins to actually add symbols to the various classes and attributes, right? Exactly. The main issue when you come with such a new solution is we can make some pull requests, but it's really hard to get a pull request approved for something that is still in early development. So let's say I come to the Active Directory maintainer asking to ask a symbol annotation that I'm using on my pre-alpha configuration as code plugin. I guess he won't be really happy to just merge because I'm asking. He wants to have some concrete reason to do that. And so we have this balance. We offer a simple way to have some reasonable name and there is probably some cases where it won't be enough and for those we will require some symbol annotation, but we already have a good solution to keep a human-friendly name in the YAML description. Cool. Right. So here we have identified the target components that we want to create and to set as Jenkins security really implementation. So this component in YAML file has sub elements. We are using the exact same logic to set up all the constructor parameters. So we are using the data-bound constructor here. Generally speaking, we are relying on all the UI binding mechanism because that's something that enforce that the code will be maintained by the plugin developer. We don't want to introduce some new mechanisms that will require to keep in sync with the UI. And we also want those parameters to reflect as much as possible as the user experience when they're just brought from Jenkins Web UI. So we expect that the forms created for the Web UI will be using attribute names that are more or less the same as the attribute levels. So here we have a configuration, disable, mail, address, resolver. And in many cases, just the attribute name is enough to have some reasonable name in the YAML file. And as you can guess, we always have some work around to switch to other implementation when required. So you also can see in these samples that we are supporting enumeration with the ID strategy parameter and for sure all everything about data-bound that set us for additional optional parameters. So with those mechanisms, we're able to fully set up the LDARP security realm and could configure our Jenkins master with those options. But there is, as you can guess, many corner cases. Typically, as we're relying on setters, there are many setters that are not really here to reflect something that end user is supposed to configure. Some of them are here for legacy reason. Some of them are here for internal binding between components, but not designed to be used by end user. So we are just reading the deprecated and restricted annotations to exclude them from the configuration as code. We also propose to enlarge the use of the symbol annotation so it can also be used in setters. So if I have Java in property with a technical name like the label string that exists on Jenkins core object, the end user is just expecting label, not label string. So we can use just one annotation to make it simpler. And for very complex use case, one can just come with a dedicated implementation for all those components. And this is exactly what we did with credentials. So what we did here is more a proof of concept of how to implement this to ensure that this is feasible. The actual support for credentials will probably require to get some feedback from the credentials plugin maintainer. The idea is to rely on a simple YAML syntax. So this one is a map syntax for YAML, maybe something most people are not really used to. So the question mark is of the key, which is kept empty because we just want to set global credentials. And the key itself is setting a certificate based on a file on the master. So we created a dedicated credentials root contributor, which handle everything required to introduce a fake attribute system. And this attribute is expecting the certificate key. And internally, it will do the get instance, get the main credential map and inject the key in the map and all that logic that we would expect to just be calling a setter, but doesn't exist in this plugin. So just this glue code, it's mostly 10 lines of code, I guess, and this NR for us to introduce full support for this plugin. So we know a few plugins will require to do such adapter code. And the idea so far is to demonstrate this is feasible as part of the contribution as code plugin. And maybe later, when this plugin is largely used, we will be able to migrate those custom configurator in the target plugins themselves. So this code will live directly in the credentials plugin and be maintained as part of the credentials plugin. What I have in mind here is the way the pipeline was introduced with support for Git. So the implementation of the Git keyword in pipeline was part of the pipeline plugin. And as pipeline was adopted, this code has been moved to the Git plugin where it makes more sense to be maintained. So I expect the same thing to happen here. I have a question here. What's the hash global there? What is that? Just a comment. The idea of this map is to say that my system credentials, there is no dedicated key for this map. This means that this is a global credential that you can use everywhere in Jenkins. And then I have a list of credentials with a specific SSH qubit key. So I'm a little, I'm a little YAML slow here. So the question mark and then it's a key of a map. So here I could use anything as a key and then I have the values as a list. YAML can be a bit complex sometimes. But if you look at credentials plugin implementation, it's internally complex as well. Okay. So you have credentials, you have system, and then question mark, does the global matter? It matters that just a comment. Right. So question mark, colon and then some items. Yeah. So to make it clear, this specific sample has been used also to experiment with the flexibility of YAML in terms of configuration and how we can expose as much as possible what is supported by the credentials plugin. We could have something way simpler if we just want to let people configure global system credentials on their Jenkins master with a single element. Here I wanted to experiment about keeping flexibility and how much line of code we have to write to offer this support. Oh, right. And so the question mark, the comment part of that means that it's a blank key, right? Exactly. Yeah. Oh, okay. So it's like quote, quote. It's an empty. That's the way the global credentials are stored in Jenkins. Okay. All right. No specific key to reach them. All right. And that's just currently the way that we're doing it. There might be, that could be changed, but it's a little, it's a little weird, right? But it is a proof of concept. So this is just figuring out, okay, we can do it. And they'll be, there's the possibility to change and improve. Okay. And so it leads us right in the status of like, okay, where are we at? Yeah. Exactly. So we know if we want to come back. Yeah, she's on mute right now. Should be on mute already and my side. Now you're on here. And you want to take over the screen. I think I did. Cool. Yeah. So you should see slides titled pictures now. Perfect. Yeah. Because I mean, we have some plugin available in alpha version. I will, I will go back to that in a moment. But yeah, I want to, I want to highlight what key features are already available in the version that you can use. So we support reading configuration file, a YAML file, both from local drive or whatever URL, we are using raw github URLs in our demo setup. There is a available under managed Jenkins configuration as code reload that I will show you in like two minutes. And we also work on extending folder in the repository. The list of supported plugins and the pieces of YAML file that should be used to configure the plugin. But of course, the number of supported plugins is not available in this folder. This is just some extended documentation to make it easier for newcomers to start using the plugin. I said that before that we don't handle Jenkins startup and like maintaining the hosting Jenkins instance via the plugin, but we want to make it easier for you to start with the plugin. That's why we provide this Docker demo setup available under pragma Jenkins cask repository that is also linked here. And actually a fork of that repository is what I used to start up my demo. We need feedback, so we can provide more features that are really needed. Version 0.3 is already available and 0.4 is coming. But you have to use experimental plus updates and details are available under this link. But of course, if you search for experimental plugins update center for Jenkins, probably the first result in Google will take you to the page that describes how to use experimental plugins. We hope to have the official release available in May 2018 and the features that will come in this release or later releases, things that we want to focus on now the support for configuring configuration file location not on the VIRL only, but git repository and branch, for example, that's what Nicola was mentioning. We want to make it flexible so you're not being interested in one specific plugin installation support is a bit tricky. There is a discussion in JEP ongoing and Nicola mentioned that sometimes we need some pull requests to another project and it may not be very easy when our project is still in alpha, but anyway, something is happening. So we can support installing plugins, I mean, different plugins in specific versions via Jenkins configuration as code plugin. Other people were when we're presenting it on different forums were asking about auto reload configuration feature. We have it on our list and improved documentation. That's something that I really want to have. So when you're talking about the features coming in the next releases, does that mean it's after May 2018? Well, we were talking exactly about it with Nicola today. There is some queue. There is a pull request waiting to be merged in another project. So if they manage to merge the pull request before we release the first version then it may end up in the first release. But if they don't want to merge it too fast because for whatever reason they may have, we may decide to release the first version without this plugin installation support. So it's difficult to say for 100%. I would like to have this plugin installation support in the first official release. Auto reload and improve documentation. This will come for sure later. Cool. And I see that you're also inviting people to Jenkins world. I was going to do that as well. Yeah. So we'll present and be available for anyone interested in the plugin to explain how we do it in more details and listen to what features are missing and what would be cool. So if you're going to one of Jenkins world, this year we have San Francisco and Nice, if I remember correctly. So we have Europe edition. So you might have a chance to do it. Yeah. So people can come and ask you guys some questions directly or see what you're working on then. Yeah. Exactly. Cool. Again, a number of links where you can find more information. Cool. Were you going to do a demo here or just after this? Or? It will happen in 10 seconds. Okay. Cool. I wasn't. Yeah. So just a summary of some more information. But yeah, I promise to show you some things. So I want to actually do this. There was a link to this demo setup that I mentioned and I'm using this demo setup to start up my Jenkins. Can you make your... Okay. Okay. We don't need that one. Go ahead. Go ahead. Yeah. Continue. So we're using Docker compose and in the demo setup it uses Jenkins config environment variable to pass the location of Jenkins YAML file in this link that I provided in one of the slides for the story with the URL. I've decided to switch to a little bit easier. And here is an example of YAML file I'm using and someone asked about configuring jobs. So here is how I have two jobs, two pipelines configured on my Jenkins doing startup. And this is how I do it. If you're familiar with job DSL or pipelines, then it should be like no brainer. So here is... Okay. This is not working because the Jenkins is not started with Docker compose and it's happening. So here you'll probably see in a moment... Oh, I hope. Oh, is it? Yeah. That's the things from Jenkins YAML. System message, some credentials are being configured. So it's up and running. And then... So when I want to make a change in the configuration, I just, yeah, for example, like get rid of that and change the system message, the simple one. I need to log in. And then the Jenkins configuration is called plugin is available under manage Jenkins, configuration is called reload. Reload happens and the system message is changed. And of course, it will work the same way for anything you want to change. So it's very simple. And one of the features that I made, but this one for sure won't be part of the first release will be auto reload. So if you keep your configuration file somewhere in your repository and you push a change to this file, you may want to configure it in a way that every time you push a change, do that. And stuff like that. So can you go back to the YAML file for a second? Just over in your editor? Yeah. Are you showing it or not? There we go. Okay. So you have the demo set up here. Right. Okay. Cool. I just wanted to see what you were talking about. Yeah. So this is what I changed. And then when we go to manage Jenkins, configure the system. So the configuration happens without Jenkins actually restarting, right? Yes. Yes. So Jenkins is called reference. We had this pipeline job that took six minutes. So when you made a change in your file, you had to redeploy Jenkins completely. Here, Jenkins is working. So it works the same way you would do it if you were using Jenkins in a traditional way. You just... Yeah. Yes. It's changing here. You like to have computers save at the bottom and the restart is not happening. So we just want to have the same... Yeah. Yeah. As well as using the data binding for the web UI, reloading the configuration as code file is exactly the same as if you were submitting all the configuration screen of your Jenkins master. Okay. So there is no restart or interruption nowhere. Right. So that's a big improvement. What people have done in the past to do this kind of configuration would be to actually save their Jenkins, config XML, or save the other XML files, right? And reloads on this here. Right. So this would be a much smoother path, even then certainly than the XML, but also just that pathway. Yeah. Cool. Yeah. So that was a short demo, but it's really that simple. You create your Jenkins YAML, you point out where it is using the environment variable, start up your Jenkins, or reload configuration. And, you know, sometimes short demos are perfect because from there you can extrapolate everything else that all the other configuration you'd want to do. Right. Yep. So give it a try. Once you get the presentation, you will have all the links available. Feel free to ask questions. My GitHub handle or Twitter handle was available at the beginning. I mentioned we are using GitHub issues and you feel free to contribute to those. Anyway, you want to contribute is a good way. There is no better or worse contribution, even if you have a command type, we are still like those. And that's it. What we preferred. And if there are any questions, I understand Lea was trying to follow IRC channels. Anything else? Yeah. We've mostly been keeping up with them actually during the presentation. Let's see. There was one more left over about, they were asking whether or not this could be used to dynamically download plugins. And I'm trying to think of what this would involve. Can you use this to configure plugins as well? I'd like to add certain specific plugins? Or is that under discussion? Well, but once again, I just got every second word from the other way. Oh, sorry. I'll talk a little slower and hopefully this comes through. Yeah. Thank you. The question was whether this can be used to dynamically download plugins from like a local repository or to configure plugins when you start up. And not to configure them, but to add them specifically. All right. So I'm working on a pull request to add support for plugin management. The main point so far is that what we want to do here is to have full control in terms of reproducibility so that if you want to have Git plugin 3.8, you will always get Git plugin 3.8. And the same dependency you had the first time you define this installation. And the update center Jenkins only offers the latest version of plugins. So we are looking for some way to ensure that we really install the expected set of plugins. And this requires some minor changes to the update center itself. So this is still a work in progress, not a big effort, but need some discussion within for our team and some more experimentation. But yeah, clearly that's something that is part of the scope of this plugin. So maybe this won't be ready for 1.0, but this will come a few later. But it's definitely of interest, yeah. It's clearly part of the scope of this plugin. Yeah, in the long run. Cool. Great. So I think that's everything. Evelina, Nikola, will you be hopping on to IRC if people have questions afterwards? Yes. I forgot to join at the beginning of the presentation, but I'm starting up the client. Okay, that's no problem. And I'll add some of the links that you have in the presentation and the link to the presentation to the YouTube description when we're done here. So that'll be good there. And let's see here. So thank you very much. Yes, that's exactly what I was going to say. Thanks, everyone, for joining us. Thank you, guys, for presenting and for, I'd also like to thank Prachma for sort of, for supporting and having you be part of the Jenkins Project, Evelina. And let's see here. I also wanted to mention next month's Jenkins online meetup. You can find on the Jenkins channel that you're watching right now. It will be on Jenkins X, which is a Jenkins for Kubernetes. So let's see here. Yes, you can always find a lot of help for Jenkins on the Jenkins IRC channel or on the Jenkins email list. Jenkins users are Jenkins IRDev. And thank you, everyone, for joining us.