 Alright, thanks everybody. So in terms of topics that I think we could address, we could talk about plug-in development, what it means to do some of the specific items that we've listed, we could talk about pipeline development, we could talk about, we could go back to the adopting a plug-in. I think we're pretty well covered there. We could take topics of your choosing. Are there specific topics you'd like to consider? Sorry, I just missed it. I have a question about plug-in developments. I'm trying to find when I'm searching through the Jenkins website and everything else, I keep on running into plug-in documentation links that are all set to read only and like normally three or four years old. Where is the current documentation for plug-in development? So, assuming I'm just looking at the wrong place, but. No, no, it's a broad mix. There is plenty of documentation that is useful even in the read only wiki site. However, the best and most authoritative is on Jenkins, on www.jankens.io. Okay, and let me, let's go there. Let me share my screen and we can look at it together. But this may not address your specific question, but let's try. So here I'm going to go to this. Let's see. Do you see my screen with the slides on it? Okay, so let's look at Jenkins.io. And so here is the, let me see that I got it. Okay, size it correctly for my screen. Here is the documentation. And now if we look at the developer guide down here at the second from the bottom, what this gives us is links to various things. Alright, the first, how do you get started writing a new plug-in that's that's actually rather uncommon now with 1800 plugins. Most people don't need to write a new plug-in but if you're interested we could go through that. There are a series of how to guides that guide us on specific specific needs and specific challenges. Jonathan was, was there a specific I don't end up when I'm searching through like that go over Google I don't end up here I end up. And, and that's that I suspect is because many of the questions are answered on the wiki. And, hang on just a minute I've got something. Oh, good. Okay. Yeah, so, so there are, there are plenty of, of things that are linked to the Jenkins wiki. Maybe we could test this one specifically. Is there a certain question that you've got a little more specific and let's look for it together here. No, well, just, I don't know. I don't want to monopolize things but, like I said, when I was trying to, when I migrated our at work when I migrated the Jenkins instance to the newer LTS, then I tried to bring in that old plug-in that I was using it just through errors. I just opened up I had the old source to the plug in and open it up and try to try to update the palm and then also it was throwing errors all over the place and then I went to look to try to solve those errors. It was missing some of the groovy parts of it were missing some cross site scripting fixes and a bunch of other stuff and I just kept on when I as I was searching for the issues I ended on the wiki and I was finding sort of old stuff, you know, pointing to like net beans plug-ins that are no longer available and pointing to IntelliJ plug-ins that are right date and stuff. And so I was just trying to figure out where the kind of, yeah, so. Yeah, and you highlight you highlighted there's a there's a broad collection of information on wiki.jankens.io I think the specific thing, probably the first thing you were doing or would have benefited by doing is this updating your Maven parent palm. Because what that does is that and if you're willing we could actually we could actually try this live if you'd like but but what there is here is this guides us to to hey how do I how do I take my older plug in that was probably using this kind of format. Yeah, get it into this format and adapt to the new new new Jenkins parent palm. I figured that stuff out eventually so but yeah, so I don't like I said I don't want to take up unless other people will find this useful I don't want to sort of monopolize things but. Okay, yeah so so the for me it's worth. I think it's worthwhile highlighting some of the things on this page, just for everyone's benefit because when you adopt a plug in. One of the early things that you'll probably do is exactly this update your Maven parent palm and the steps that this provides are necessary preparatory steps for some of the later steps like using the Jenkins bill of materials. So by by saying okay we're going to do updating your Maven parent palm. This change. Okay, it looks pretty simple right we're going to change the parent from being without specifying a version to instead now specify a version. Include the relative path markup and set a separate property for the Jenkins dot version. That exercise alone will now update you and now here you should probably then most of us should look at that version number and say 1.625 is very, very old. And, and now there's a little bit of extra guidance choosing let's see it's if I look at it this way. Here it is this. So you remember I said hey 1.625 is old. There's a page in this set that says choosing a Jenkins version to build against. And Jonathan one of yours is you were updating to a Jenkins LTS version and you're probably not going to do anything with that old plug in on an old Jenkins version so for you updating to a new Jenkins version is probably a good thing. And so this guidance says okay gives us some instructions on how do we choose what Jenkins version we should make as the minimum value for this Jenkins dot version. And then it gives you some tradeoffs okay if you choose to keep it low, you can increase your adoption. If you go make it much, much more recent, you can use more recent features. You should probably not use something that's older than about a year, because things that are older than a year have sort of fallen off the edge of the update center. And so, so when it says when this one says 1.625, and you go looking in the history and realize wow that was eight or nine years ago. You can clearly make a move to a newer version, and you can choose a much more recent version saying okay I'm going to choose. And now we look what does it recommend and this page says, hey choose either 2.263.1 or 2.277.1. And the cool thing for me about this page is it updates automatically based on LTS versions. So it's going to six months from now show us different versions as the recommended base version. See your parent palm, good first thing now. Now you may say, oh, oh, oh, you do that, and you get this message. Oh, I'm getting require upper bounds messages and these are the kinds of messages that happen. And guess what this is a great excuse to then look at Oh maybe I should switch to use the Jenkins bill of plug in bill of materials as referenced here. Because what it will do is solve most of those many of those kind of problems for you. So you don't have to solve them anymore, because what this bill of materials concept is is there's a repository in Jenkins that has a bunch of automated tests that test all sorts of plugins in combination with each other at version numbers, and then you go towards those version numbers in this thing. And all you do is use the results of other people's testing to decide what version you want to base yourself on for a particular dependency. So the now I fear this was such a novel concept for me that it complete it took me a little bit to think about it. Do you have questions about how how those dependency version numbers are managed or things like that. No, I have to play with it a bit first. Okay, so, so this is that, okay updates your as you choose a Jenkins version, you can update to use the plug in bill of materials, and the plug in bill of materials will simplify dramatically your management of version numbers of dependencies. Okay. And I, I cannot, I cannot praise this nearly enough because in the example of the plugins that I maintain, even some of the low volume plugins, it has been a dramatic improvement in the simplicity of these palm files by being able to use the bill of materials instead of calling out every single version number of every single dependency. Okay. Great. I had a question, Mark. Yes, please. So, what level of autonomy have the plugins in regard to dependency that for instance, I beg Apache HTTP client, it is very common, or is very used across multiple plugins. So if I if the plugin that I'm using, it depends on that particular library. So I can upgrade it just for my plugin, or we have an impact on remaining plugins how