 Our agenda today shows, let's talk about open action items. Then we've got a topic from Oleg on Docker images and proposed centos image and multi-platform images. If Natasha makes it to the session, we'll invite her to talk about the plugin installation manager tool. I'm here. Oh, great, Natasha, thank you. Thanks for being here and welcome. We'll look for, are you comfortable with that being on the agenda, ready to talk about it? Yes. Excellent, thank you. Then after that, if Alex is here to talk YAML configuration, we may optionally do that. Then Windows installer status with Alex are all great to have Alex here. And then the performance test framework is final topic on our agenda today. Anything else that needs to be put on the agenda? Great, okay, so let's do a brief review of the to-dos. I still have the open item to review the jet for the Docker to submit the Jenkins enhancement proposal for Docker operating system support. My apologies, I will do it, I'm sure. Oleg, you've got one on Windows support policy. Anything that you want to report there? No, nothing. Alex, we've got one for you with regard to code signing infrastructure with Olivier Vernin. Anything you'd like to report there? Yeah, so I've been working with him on getting an Azure agent up in the trusted infrastructure. So we have kind of the init script ready which installs the necessary like Java and Visual Studio build tools so that we can do like MS build and sign tool. There's an issue right now that we're kind of working through with credentials. So, but once that's there, we should be able to spin up Windows agents in trusted to do this, to do Windows builds as necessary. Excellent, thank you. So, so, proceeding Azure infrastructure, infrastructure in progress, issues being worked with Olivier. Excellent, thanks very much. And excuse my clattering keyboard, I promise to buy a quieter keyboard, it'll arrive soon. All right, Oleg, Docker images. Okay, so for Docker images, we have two parallel stories, just a second I will share my screen. Oh, I'm in VPN. Oh, I think I have to stop sharing Oleg, if we want you to share. Zoom. But I would say that it's also an advantage of Zoom because we don't mess up the video recording like we usually do in Hangouts. Right, so I think I've stopped share, I think my screen is no longer shared. Yeah, do you see my screen? Yes, we do. Thank you very much. Okay, great. So, yeah, regarding Docker images, we have two threads ongoing in public, maybe even three, there is also a discussion about UBI. So yeah, one of the things which we have right now is this pull request which was submitted by Arno about adding CentOS support for Java 8. So Java 11 is out of the scope, but yeah, this pull request is ready to go from my opinion. And basically, why did it go to the agenda? Because I wanted to coordinate with Alex about Murchank. Because Alex, as far as I know, has access to trust the info after Windows installers work. Yeah, that's correct. I have the, I can see the core lease containers, master branch job. So I can monitor it as necessary. Yeah, so basically we can merge it in a moment and once we merge weekly releases should be reprivisioned. So there were some patches in this pull request since the last changes. Yeah, basically CentOS support will start from the previous weekly release. So once we integrate it, we will get one release on trust.ci. And if something goes wrong, yeah, that's why we're here. Yeah, I'm ready anytime this morning or I guess whatever time it is for you afternoon. If you're fine, we can just click the merge button. Yeah, sure, go ahead. So if we need to change the agenda at the end of the meeting, you know why? I tell you, there is nothing sweeter than watching live merge during a platform sake meeting. We should do more of this. I like this. Oh, okay. Well, you see images in Windows are different from images in MacOS. So it's not run because it should be ship and the Italy flock. No, yeah, it's not about cost to concordia. You already know this joke. Okay, so. I'll monitor and then if it's, if there are any issues, I'll bring it up if there are. Yeah, so this is a part of the story. So probably we will need to do something for Java 11 eventually, but yeah, for now, Java 8 is enough. The separate part of the story is about UBI. UBI is a universal based image which is now shipped by Red Hat. So yes, Santos is formally shipped by Red Hat as well or by Santos project, but yeah, whatever. So here in the threat, there was Scott McCarthy who joined the discussion and offered to have UBI based image because UBI based image is something which is more liked by enterprises because yeah, it's a standardized image. When you use it, you have opt-in support from Red Hat, et cetera. So there was a proposal to have it. One of the things why this proposal was delayed to be is because of expert license conscience because and user license agreement for UBI says that well, you have to comply with U.S. expert rules and what it means that you as an organization are supposed to ensure that this image doesn't get shipped to restricted countries and region like Iran, North Korea, Crimea or whatever. And we had a problem with it because basically we have no means to ensure it on Docker Hub and what was in discussion is actually, well, yeah, it's one, it was considered as a pretty serious issue to discuss. Scott thanks a lot to him, he did extra mile in order to verify it with legal and you're basically at the summer of the discovery that it's not worse so that all other images than we should because Ubuntu, DBN, et cetera, they have pretty much the same restrictions. So, yeah, it's a concern, but yeah, it's a concern which we already have. So probably it's something we need to bring up with CDF as a part of transition of infrastructure. I'll probably bring it up with Tracia but advocacy and outreach meeting. So yeah, basically what said, Red Hat isn't going to ban it to assume you if you break the export compliance, it will be the US government. Yeah, it sounds really reassuring, but yeah, that's what we have. So yeah, basically I don't think that this is restriction for us or what I, at least it's not a big obstacle to get it. So yeah, I just asked who is interested to implement it because it means that we need to implement it which is easy part. Then we need to release it, deploy it and somehow maintain it, which is less easy part. And yeah, if somebody steps up, we can integrate it. So maybe we'll have some updates in the next meetings. There was also a threat about using Quay. So Quay is another like solution for containers delivery which supports basically Docker and Rocket. But yeah, it's subject for discussion. So again, if somebody is interested to support delivery for Rocket, okay, let's do so. If not, okay, then no. Would this be instead of publishing to Docker, publishing to Quay or would it be an addition? No, I think there is no way we stop shipping to Docker Hub unless CDF says that Docker Hub doesn't comply with CDF rules. And then we need to do so. But since Kubernetes and other things have been distributed from Docker Hub, I don't think that it's something we should expect. So what would be the benefit of using Quay then? So one of, so firstly, it's another delivery platform which is used by some companies. So again, if you use UBI combined in case with Quay, it can help this delivery. And another thing that it can enforce is country restrictions. Whether it's better or worse, but it can enforce that if there is a decision to have some enforcements. But I mean, if they're still available on Docker, is the restrictions on Quay really don't matter, right? So I'm... Yeah, so I do have opinions about US restrictions, but I still need to get my visa. So yeah, so just not to dive into this topic. Yeah, regarding this, so yeah, let's see where it comes goes. But yeah, maybe there will be some updates. Another related story, it's our multi-platform images. So basically I wanted to ask Mark and maybe Baptiste about this pull request, just a second. So I guess this one. So this is for, so long story short, there is an idea to have multi-platform images including platform like IBM and other things. Docker Hub supports that. We have to link which is integrated. Our next steps was to enable deployment of experimental branches to Jenkins for a while. So this is our GitHub organization. But here, finally, it looks like we do... Oh, yeah, it looks like there are some action items. So the fix from master was merged in. So now it's just failing like the normal master is failing with the resource access denied. I was looking around online and found some people who said you need to call Docker login before doing a push, but I don't know. Yeah, that's new. It was getting past that and failing at the publish stage. Okay, so it's probably out of memory or whatever. Yeah, who knows. But yeah, thanks a lot for looking on that because yeah, I just wanted to ask about our next steps and yeah, I opened this pull request and it looks like we already have next steps. So I do have a PR in to try doing the Docker login, but since it's a PR, it's not gonna try to do the publish. So I don't know if that's something you wanna try in that PR or not, since you have trusted access. If we merge it, what would be... It's the second one, yeah. Try login prior to push. Okay, so in the worst case, we break what? We break publish experimental, right? Yeah, yep. The publish experimental doesn't really work right now. Okay? Right. Okay. And we can always refer to it if it doesn't do anything. Yeah, that's right. So it fails because of the same issue, I guess. Okay, basically it's the same issue, but for other images. At least we know that it's not related to Java alone. I need to reconfigure my browser because there is a Zoom panel. And when I have this Zoom panel, I cannot navigate between tabs. Okay. So where was I? Give me some extra bin administrator. Okay, so you will need to merge with the master again, right? That's correct, yeah. Do you have access to this branch? I don't have access to anything on the Docker repo. Let's try to fix it. I believe I can give you push permissions for a particular branch. Don't choose the master. It's because, yeah, you still need to be a collaborator in this repository. Right. Okay, I'll figure it out after the meeting then. So just to save time. But yeah, thanks a lot for stepping up because it was one of the foundation projects for this specialist group. And nobody expected it to stay around for one year. It would be great if you find a creative over the line. I wanna run Jenkins on my ARM server, so that's why. Yeah, I don't have ARM server anymore. Yep, that's great. So thanks a lot for helping. Excellent, thanks Oleg. Next topic was Natasha on the plugin installation manager. I think Oleg, had you finished, Oleg? Excuse my disrupting. Yeah, that's perfectly fine. I was looking for a stop chain button. That's why I was so concentrated. Natasha, would you like to take over? Yeah, sure. Okay, so I put together just like a short presentation and then I'll actually do a demo. So you guys can see my screen, correct? Yes. Okay, so yeah, my project for Jenkins Google Summer of Code was the plugin installation manager library and CLI. And so kind of the motivation behind this was to offer users better control of which versions of plugins they install, be able to download plugins before Jenkins even starts. And then there's been a bunch of different implementations of plugin management across Jenkins. So the goal of this is to unify those and hopefully just use the one library. So for the first part of this, I've been working on converting the existing install plugins bash script from Docker, from the Jenkins Docker to Java. And so the reasons for this are just because of the limitations of bash, it's difficult to maintain and extend. And then it doesn't get all of the current update center metadata. So there's kind of two parts to my project. There's the CLI part and the library. So this is kind of what I've implemented so far for CLI options. So you can pass in a list of plugins that you wanna install and or a path to a text file that actually contains the plugins and their versions. You can specify where you want them installed, which Jenkins war file you wanna use. And then this is kind of in the works, but one of the features that we wanna implement is being able to view all of the security warnings for plugins. So that's not quite there yet, but you have the ability to see all security warnings and then hopefully we'll get to the point where you can just see the ones for the plugins and the dependencies that you wanna actually install. So kind of the way this works is we find the existing installed plugins either in the war file or in the directory that you specified, the tool will go ahead and download the requested plugins and ignore them if they're already installed or upgrade them if the existing version is too low. There's the ability to specify which update center. So I think actually right now this is hard coded but the goal would be to also do what's currently done in Docker where you get this from the environment variables. And then there's the option to download from the latest or the experimental and then after figuring out like where you're gonna download your plugin from and what those dependencies are, you'll go ahead and download that and the dependencies as well. Okay, so that's just like a quick overview. And so I have this repository, I would love feedback maybe after the call or when you guys get a chance. Okay, so let's see, I need to just switch applications. So I'll go ahead and do a demo now. Okay, so you guys can now see my terminal, correct? Okay, so I just created a plugins.txt file which has all the plugins and the versions that I wanna install. So if you don't specify a version, it'll download the latest one and then you can also use some of the modifiers like latest or experimental. And then I also threw in a plugin that is not a real plugin. So that should actually work. And then we'll go ahead and run this. And then I'll pass in the war file that I had as well. And then we'll pass in some additional plugins. So, let's see, did that not. Oh, that's weird. Okay, so, sorry, I think it should have defaulted to the list of plugins that I entered, but let me see. Oh yeah, okay, so yeah, actually I did. So yeah, I didn't actually specify somewhere else. So the default is just to do it and to check the same directory that you're in. Yep, so you can kind of see right now the war file that I have some existing plugins and then there's nothing, no plugins like currently installed. It'll look at each of the plugins that I specified and we'll download all of the dependencies. And so after that, you should see basically all of your plugins installed in a folder and then information about the failed plugin as well. So yeah, that's pretty much what I have so far. Let me know if you have questions or feedback. Would definitely love to get input. Nice work, Natasha. I noticed that it may not be resolving recursively the dependencies of the things that were downloaded. So for instance, there's a plugin in your list of downloaded git.jpi which has a mandatory dependency on git-client.jpi. So you may wanna investigate a little further to see if you need to recurse on things that you've downloaded to also get all their dependencies. Okay, yeah. Nice work, this is excellent, great work. I was just needing this a day ago so I am intensely interested in what you're doing. Okay, yeah, we definitely love your feedback. So I'll check out the current issue and then I think we're hoping to release like an alpha version soon, just to continue to get feedback and start getting people to use it. So you can be an early adopter if you want. Thank you, thanks very much. All right, and once the tool is stable enough, we can consider integrating git to Docker images because basically the idea of the first phase is to have something similar to how Docker operates. I mean, install plugin state XT with some added features already. And then we probably consider adding git to other tools because we have a lot of implementations for coding and Jenkins. Right, excellent. Thank you very much, Natasha, great work. Next topic is YAML configuration support for the Windows service wrapper. Maybe we should ask questions. Oh, sorry, yes. Are there other questions for Natasha? Excuse my being a little bit push forward here. Yeah, and if there's none right away, we have our Gitter channel so people can feel free to post in there, ask questions in there, give feedback. Mm-hmm. Excellent. Yeah, thanks a lot for that. And you also have a company in Jira, so if you try it out and discover something, these are the important issues. Thank you, Natasha. Great, so I think our next topic then is YAML configuration support in the Windows service wrapper. And Alexander Grigorev, I believe you're here and you and Oleg. Yeah, I'm here. So, for this time, which I made, I am able to organize paperwork and apply it to my university and just had a quick conversation with Alex Erl about, it's the next question, about this Windows install implementation. So I think we should sync up with him and implement my idea to use Windows commands like SC, create services for Edge. That's the idea, that was the general idea which I made in my proposal. Yeah. But I need to understand how can I, how can I build it and implement it. That's why I will sync up with Alex. Yeah, he gave me basic information and soon I will follow up with additional questions. Yes, that's it for now. Thank you. So Oleg, were there other topics there? I'm not familiar with the Windows service wrapper and YAML topic. Anything else that we need to discuss here in this session? Not at the moment. So the tool itself works well. It's somehow related to our Windows support policy because one of the reasons why I brought up this question because I maintain two Windows components, Windows service wrapper and Windows process management library. So one depends on .NET and now it targets .NET 2.0, which is quite old, but on the other hand it's pretty useful for some people who still use Windows XP, etc. So I think about updating to your .NET versions because it would help us a lot with various stories. But at the same time, yeah, I'm not sure what the Jenkins users say about that. And yeah, I have exactly similar issues with Windows process management library because it uses WinAPI and currently we target WinAPI for XP3. But again, there is interest to maybe bump two Windows 7, whatever APIs. So yeah, these two topics are my main drivers for Jeff. I hope I will get to that. In addition to that, I hope to spend some time on Windows service wrapper as a project. But yeah, so far I was doing a lot of things in other areas, so I haven't got to it yet. Alek, I think maybe I could help with some of the things we're testing as far as I... Maybe you should just break down this in mid-nodes and I could use some return machines and implement some testing. Testing for Windows service wrapper? Yes, because we need to check and sync up with modern Windows systems. Yeah, right. The current situation is that I tested only on modern Windows systems. Currently, both WinAPI and WinAPI have a test automation on Appear because Appear offers much better Windows system than CI Jenkins.io. And yeah, I run tests on... Yeah, maybe I should just share the screen. If it's interesting to anybody, I will just show it. Okay, do you see my screen? Yes, sure. So both WinAPI and WinAPI are based in Kiki's repository. So it's a pure data project. It's been published to Nougat at the moment. It has insane number of installations. It has more stars than Jenkins X because it has been widely used in many projects. But yeah, regarding CI4, so how we do test automation here? So firstly, there are some tests in Windows V tests. So basically it's unit tests mostly. Yeah, if you're familiar with JUnit, you won't be shocked because it's just NUnit which is basically JUnit but for .NET. So there is a bunch of tests here written in such form. But none of these tests really checks whether a service has been installed, et cetera. So we don't really have integration tests for Windows service management. And maybe it's one of the topics which might be interesting to you because it doesn't have no idea how to properly do that because my understanding that whatever you test for Windows service, you need a clean Windows virtual machine or container which you need, then you need to tear it down. So it's not something which I have at the moment in this test suite. But yeah, it's something we could do. And basically regarding CI-CD pipelines, this repository has a full release automation which happens on out there. These deployments to Nuget and to GitHub releases. And yeah, regarding the CI built itself, again, it's in up there. So you can see the up there YAML definition. So here we basically built on whatever latest Windows server. So right now it's Windows Server 2012, I believe, up there. We take any CPU. So basically whatever machine CPU up there provides us. Yeah, we can use configuration matrixes, but it's not configured here at the moment. And here we use Visual Studio 2013. So it's a target Visual Studio for the current range. So it's pretty compatible with newer version section. And here you can see that there is some magic because we need to complete code sign. We need to inject assembly info. So in Jenkins, there is assembly info patcher plugin or something like that, which allows to modify assembly information in Jenkins pipelines. IPR just does it natively. And then yeah, there is some build which packages everything we need to get after that. And then it runs this, we can just produce the DLL with any unit. But yeah, you get all artifacts published. So as an outcome of this pipeline, you just get second. It's a bit slow for me. So you get a build lesson. Yeah, and you also have artifacts published. You have test reports for tests included into the package. And if you want, you can manage deployments from this interface again. I'm just not signed off. It's not signed in. So you can see proud motion, but actually you can manually trigger promotion like promoted builds plugin in Jenkins. So yeah, it's available up here for Jenkins. We don't have similar functionality, but for Jenkins, now there is a Google Summer of Code project for supporting pipeline and promoting builds plugin. So one of our students plastic is working on that. Hopefully we will have some updates next week at the demos. Okay, so yeah, this is what we have right now. And there is no integration test. And if you're interested, it could be one way to explore or another area, just see where you could improve test suites. Because yeah, obviously, none of the information is ideal. Maybe, yeah, it's still light guys who have 100% coverage, but definitely not this repository. Yeah, great, great. Okay, I hope we record this session in order for me to repeat it and then follow up with questions, okay? Yeah, this session is recorded, so you will get all this information. Okay, great, great. Okay, any questions? And for me, thanks very much. Oleg, thanks for the overview. Thank you. And so our next topic is... Oh, next topic is Windows installer status, Alex Earl. So we're going from one Alex to another Alex. So I kind of gave the update on the trusted CI Windows agent already. So I won't go over that again. So I've had a few discussions with Daniel Beck about some security stuff to try and add to the Windows installer. For one, we automatically currently add a firewall exception. And it's to a Java process, not to a specific port or anything like that. So that could raise some security concerns. So his request is that we turn that into an optional feature to install. So I've added that into the installer so that the user can select to install a firewall exception, and it will warn them and say this is not recommended practice. Generally, a firewall won't be needed unless you're going outside of your network anyway. This was something I added. Another thing I added is... So the installer allows you to select a user to run the service as. And currently it was selecting the local system account as default, which is actually also possible open to security issues. So now it mentions that that is not recommended to run as the local system account. And it specifies the entry area to add in a username and password as the recommended method. So really it's... I just need to get testing, but I feel like I need to get builds that are from either ci.jankins.io or trusted before asking people to try installing it just because I wouldn't want to install something that some random person on the internet built. So that's the concern there. But really it just needs a lot of testing. I started looking at a way of unit testing the installer. There's not really anything out there right now. And it's just kind of for basic stuff. I want to make sure that going back and forth between the pages and the installer works correctly, the fields are set correctly, that you can override things via the command line as a lot of people do for deployments to multiple machines. That's not necessarily something that will probably be done with Jenkins, but it'll be useful with the Choclity package because Choclity you call the MSI with the command line parameters to set up what you want. So that's how you expose those parameters to a user of a Choclity package. So I have a Jenkins file in my current repo that will build the installer, the MSI installer, and then it will package up the Choclity package based on that installer. So, yeah. But that's all stuff we need to figure out for getting it on the infrastructure for publishing and so forth. So once we have builds on either Trusted or ci.jnks.io, it'll help a lot. One question about warnings for system administrator. Have you considered having administrative monitors and Jenkins for that? I have not, no. Yeah, it's probably a quite separate story, but maybe once this feature is integrated, maybe we should make it one step forward so one Jenkins user from Jenkins Web UI. Yeah, that's a good idea. I'm not sure how to properly resolve it. We could probably do that. Okay. So I think some good progress has been made with builds and stuff. So, you know, I started this a while ago, so I'd like people to start testing at some point, but I really, like I said, I want it to get builds from an official quote unquote official source before asking people to test it. And that's all for me on that topic. Thanks very much, Alex. Excellent. That's great results. Oleg, you and Apiudaya had a topic on status update for the performance test framework. I don't see Abu here. Do you want to take a brief summary of it? It looks like there's great, great news to be shared. Yeah, I can show that. So do you see my screen again? Do, yes. Yeah, it happens too often today. Okay, so now what a great news. So, yeah, the last platform seed meeting we did a demo of how performance testing framework would be operating. So if you scroll down, yeah, there are some notes about it. But basically what was our plan is to finish the integration and to make it a part of the default pursuits. So this is what we actually completed. So for example, if you go to Jenkins test funds, you can see, yeah, actually, there is a parallel work about having a release drafter and the release automation enabled for the repositories. So if you're interested, I can talk about it in the future. Yeah, there is a mega list about that. Yeah, you can see that in 2.50 we integrated plugin benchmarking. There was one enhancement in the 2.51 in order to reduce sample for dependencies because it was using perfection. But basically any Jenkins plugin user can just go and read the documentation how to use that. So there are some examples and links. Yeah, it's released. Same, it's already available within a plugin form. So here last plugin form release, which we had last week at this. Yeah, it also supports running benchmarks. So basically as a plugin developer, what you need to do now, if you use a latest plugin form, you define minus the benchmark profile. Yeah, it should be a minus P might be. Maybe, but yeah, it's something I will check. But yeah, basically if you do that, you get the benchmark crying and all benchmarks configured in your repository will be operational. And it's also integrated in the CI Jenkins IEO. So we did edit a step for pipeline library. So last two weeks ago we had a discussion with Olivier Vernin about how to properly integrate into the repositories. And here I'm not sure whether it's linked in this pretty long at least. Yeah, now we have a method for pipeline library, which does run benchmarks for you. It includes some steps inside which automate the things. So we have ours run benchmarks. So basically it's just a pipeline sample, which does it. So what happens here? It runs the benchmarks on high-man machines. So one machine switch, almost physical ones. You may see that we use local resource plugin. So we ensure that we don't bring down the entire instance and the resource capacity, because these machines also use the four-seconds test harness, for example, in Jenkins Core. So we don't want to cause noses. And then yeah, there is just report publishing happens. So if you're interested to see it in action, there is a role strategy plugin. So role strategy plugin already has it integrated into Jenkins file. It has a lot of benchmarks in the repository. So performance is our configuration escort instance for this. But yeah, now there are some benchmarks here. For example, there is a number of benchmarks, which we already use. For example, benchmarks for folder access. Here we pre-configure the instance. And then yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, there is a lot of code because we need to create a big instance to run proper benchmark for resolution. But yeah, basically the tests are something like that. So we just, so we have a TLS storage which enables security and then we just, just one method and all the underlying implementation is telling the expression checks and other things happens here. So this is the benchmark, and then there is a lot of examples here. And yeah, we are not doing it just for fun because so a beauty is going ahead the schedule. So we are basically on the phase two of the summer of code and phase two is about performance improvements for all strategy plugin. And that is one of first changes, which is also backed by existing benchmarks. And here you can see reports generated by Gmh, which shows that for example, well, 3,000% for one benchmark, because we rely on Cache and get something like 150, 182 for other benchmarks in the list. So we have pretty good bump. There are some unknown degradation things, but yeah, it's well, we still running on virtualized environments so plus minus 10% it's not something we care much about. But yeah, this is an example of this framework in use. All components integrated, there are some panic release for configuration as code plugin support because we moved some framework bits for G-Casks support to G-Casks plugin. So there is a topic on me to have a new G-Casks test harness library so that we can release that. But yeah, basically the function is already there. It's already integrated into the master branch. Yeah, it can show. So we still have some time on this. So yeah, oh no, we don't. We actually, we've hit the end of our time, but if you've got topics, I am fascinated by this, Oleg, because for instance, I need to assess the performance impact of the transition from JGit 4.5 to 5.4. And so you have me now very interested, very intensely interested, so. Yeah, so you can just start using create everything is in place. So here for example, there is example of Cask benchmark. So Cask benchmark is much more simple than the previous example I've shown because basically all the magic happens inside different classes. And yeah, so oh, it's a framework bit, but what we can do, we can reconfigure the instance from YAML file. YAML, so yeah, performance, JGit. Yeah, so I guess it's a sample Cask. So here's for example, YAML file where you pre-configure our strategy. So this is a configuration for ownership-based security. So this is an engine which uses ownership, you know this? Oh, no, it's not. It's just a common sample. And yeah, after that, we get some agents, et cetera, and we can run benchmarks that save a lot of time on pre-configuration of the instances. And yeah, it's something we could use for the cases as well, so you don't need to know Java in order to pre-configure the instance in Java. Instead of that, you can use JCask plugin for the benchmark. Okay, so yeah, everything is either ready or waiting for the release. So there is a staged blog post. Basically, it was ready yesterday, so the ball is on me because I need to deliver one batch to JCask plugin so that we get it released. But yeah, the functionality there, so if somebody wants to try it out, just do it, and the whole strategy plugin will be a good example for that. Thank you, that's great. So, Alexander, just like you, I will be reviewing the video of this afterwards to be sure I catch up on all the things that Oleg just showed. Thanks very much. That's excellent. We have reached the end of our time. I believe we've covered our topics. I've proposed a future topic as release drafter. Oleg, I would likely put you on that topic as the most experienced. Would you be willing to have that as a future topic? Well, I'm perfectly fine to do that. So yeah, I'm finalizing some things for release drafter, but yeah, if you're, basically, I cannot share my screen for the end. So if you have a couple of minutes. Yeah, so Jenkins is here, you're there. So on Jenkins, you're there, you can find, yeah, so yeah, there is introducing global promote configuration for release drafter and whatever. So basically this threat started in May and now it's close to completion. So we have some documentation pending for release drafter, but how it looks like. So we can take a repository, let's say, configuration of Scott Poggin. So since we talk about that today, maybe, here you can see that there is some history of releases. Actually, he's a staged release. So it's a draft, which includes the patch I was talking about, which we need to fully release in the blog post. And yeah, basically this change log is automatically generated based on pull requests and on labels. So you may see that there is some particularization here. And it comes just from labels and from pull request titles. And there are some things like, for example, of the automatic resolution of JIRA differences. So in a change log, it goes as a hyperlink. And yeah, here we get such configurations generated. Regarding the configuration itself. So we spent some time in order to have a solution powered by a pro board and global configuration. So basically now we have repository in Jenkins, which does includes a lot of configurations. And if you open the release drafter settings, they look like that. Because all is generalized and it's stored in a GitHub repository. So it's GitHub, should be the job. I'm not sure what's the link. So yeah, there is Jenkins.github, which stores some shared functionality. For example, Daniel has added security code of conduct there. So now all the repositories have the same policy references from GitHub metadata and when you submit a pull request, you actually get the list code of conduct suggested. So it's automated by this repository. And here we also have dot bit hub to release drafter YAML. So yeah, it looks a bit clunky, but basically this is a configuration where we have. So yeah, there are replacers. So there is template which we generate. There are some label machine policies. So if you want, you can skip change log. Or there are automated things which will be in the repository once we get new release of release drafter. This is an application we use. Yep, it just works. And right now we have 23 repositories in Jenkins which use release drafter and counting. So we updated almost all development tools because yeah, I was doing a series of releases and to save time, I just enabled the release drafter the right way. So you can see there. So this change logs have been tweaked a bit because the release drafter doesn't generate such links at the moment. So yeah, there are some areas for improvements, but basically it generates a draught for you which we can use. Okay, questions. So the crucial piece is I enabled it on one of the plugins I maintain. It's proposing drafts and then I choose when to publish it. Is that right? It's not automatically publishing. Exactly. Yeah, there is documentation underworks. Somewhat. So yeah, the comment is drafter usage. So, what's going on? Here's a browse link for that. So, okay, here you can see that there are some guidelines how to use it, how to release with it. But basically you just integrate the pull request, you mark a label pull request if you want. And then when you're ready, you do standard release flow using premium release, like, you know, whatever, it depends on your tool chain. And then you just go, I didn't edit the link here, I'll fix that. But you go to the link and edit the release on your own. So you prepare a final release and then you get it out of the door. So the list drafter just prepares a draught for you. Excellent. Thank you. My experience was quite positive, even as inexperienced as I am with it. So that was a great first experience with Platform Labeler, the vitally crucial plugin installed by maybe 200 installations. So that's great. Thank you very much. No dash. Well, there are so many typists, so I really wish you could play them to the end of the video. Yeah. There's a plugin. So it's also known as much with this plugin, test plugin or something like that. That is, I don't know why you would say such a thing, but you're absolutely right. That is my, it is my sandbox. Thanks everybody. Let's close the meeting. Thank you very, very much. We will meet again in two weeks. All right, thanks. Thanks everybody. And copy, an archived copy of the video will be posted into the meeting notes. Thanks. Thanks Alex. Thank you, bye.