 Welcome everyone to Google Summer of Code office hours. It's the 24th of March. Thanks for being here. Yes, reminder, let's behave according to the Jenkins code of conduct, be nice to each other. Sagar, I believe you had a question or you had, you wanted to share with us some progress you've made on your proposal. So, and we've got Gareth on the line who may be able to help and guide. Yeah, so I made a proposal for the Cloud Events plugin for Jenkins and basically in that plugin there are many two modules that I made and the listener one. And I made a proposal for the first module with, by looking into the first I looked in the source code of the statics gatherer plugin and I made it with respect to that because our plugin is mostly like that. So I shared my Google Doc in the chat link. Maybe you can look at it here. Excellent, thank you. So, and that's a good behavior that we want to reinforce. The sooner we get publicly shared project proposals, the more effective we can be as reviewers of those project proposals to help guide you and others can look at them and say, ah, yes, that's how a good project proposal works or look, here's what the feedback was from the reviewers on that project proposal. Very good. Regarding that proposal, hello everyone. Hello. Like I'm working on the plugin like plugin tool, plugin manager tool improvement, that project idea. So on that idea, like there are various issues which are mentioned, like which are labeled as enhancement on the issue, like GitHub issue tracker. So, Ulik, I'm sorry, Ulik not. Mark, can you like give me some idea how many issues should I target for this GSOC like this year? There are around seven. And I think that's up to you. Explore them, see what you think it might take. You're the best estimator of what you think you should put into the project proposal and plugin installation manager is a particularly interesting one because it is increasing use in the Docker images. We're using it more and more. In fact, we've got a pull request right now proposing to completely replace the old way of doing things. It was a shell script with plugin installation manager. So do some experiments and use those to estimate for yourself which things you think you should include in your project. Okay, but can you just still give me an ideal number like what would you suggest? Because I feel if I give a very less number like just two or three issues which I feel that I can solve then like any expectations which the community has or the mentors have anything like that? I actually know and let me, I've got Rishabh on the call. So this is a great excuse to explain why there isn't an expectation. So Rishabh last year worked on one issue, right? One issue it was improve the performance of the Git plugin. That was one. And that one issue took full time for four months, wasn't it Rishabh? I mean, we spent, we spent, he spent months on that one issue. So if it's one and it's a big one that's perfectly fine. If it's several small, that's also okay. So, and the other is Google Summer of Code allows that we can adapt and refine as we go through it. So again, to Rishabh as the example, last year we discovered roughly halfway through that we had not done nearly a good enough job of describing things at the beginning. And Rishabh had to do a bunch of research, right? He had to do creative, very, very challenging question answering and he did very well at it. But it's, there is some flexibility there. Better for you, the more you do in advance. And that was another thing we learned with Rishabh, right? Is better that we do more things in advance during this preparation phase. But a few is okay. If they're given plug-in installation managers relatively new state, I would make a guess that you could do three or four because you'll find some of them will be easy. Some of them will be more difficult and that's okay. They're like, there's some of the issues with just say to replace the, like replace simple system.out, system.outprint line commands with the logging, like logger class, like create a logger class and all that. So some of the issues are like that. So yeah, I'll take into that. Thanks for the insight. I think that's a good way showing in your project plan that you have looked at the issues, thought about them and considered which ones you should do and which sequence is a good indicator. Oh, I've thought about this. And I would do this one first because it looks a little easier. I would do this one next because I would develop more skills and be able to work on it next. So yeah, that's it. So like I can write all of this in my timeline. What should I do? Okay. Thank you so much Mark. Thank you so much. Thank you. Yeah. And thank you, Rishabh for being the example. By the way, much appreciated. Yeah, thank you so much Rishabh. Thank you. Thank you so much. I just wanted to add one thing to what Mark said and correct me if I'm wrong Mark here, that if you see, let's say 10 issues for a particular project, the priority should be done on the basis of the community value, which you will provide by solving any of these issues. So if you understand the plugin well, I am assuming that you will be able to understand that if you fix a certain issue, you will be able to give a certain amount of value to the community which who is using it. So that is how you should prioritize your issues and that is how you should, I think, plan your proposal. Like for my project, Thank you so much. it was very clear that we had one problem which if we are able to solve correctly, we will be able to give like huge benefits to the users. That was dependent on our project, of course, but that was clear from the beginning. Yes, yeah, actually it's a very good point. to like look up to for the issues whichever impacts the community most, I should go for those first. Thank you, thank you so much for the insight. Other questions? I have a question, but that's regarding the related code. So is it fine to ask here? I mean, it's more like a coding question, okay. So I have a question regarding in the status gatherer plugin. There is one class named property loader which acts. So which is actually, I guess, yeah, whatever the end points is being saved by the user from where to send all those statistics is being sent. So how, where all that data is being saved by the Jenkins. Maybe I didn't explain it very well, but I can share that particular class on the grid. I presume it's down to sort of, it's like global plugin configurations, isn't it? But we're emitting events. We need to have an endpoint, I presume. And I don't know whether it's just a simple webhook endpoint. I don't know whether we need to do any styling of events to make sure they're not manipulated. And I don't know whether there's any PLS configuration we would need to do to sort of say, we need to verify or not. So I think there's quite a good example of that that has just been added to the Tecton client plugin of global configuration for saving instances, saving information about the Tecton cluster. So I think there's some stuff in there that might be handy. And so looking at the specific code that you shared, so that looks like it is a data object that's, yeah, loading data from a resource bundle. And then I assume has the, I don't see anything immediately that saves it back. So it looks like it's taking in data, but I don't see anything on it. I was just gonna say, well, it looks like it's, yeah, loads of the resource bundle, which has sort of defaults. And then there are system properties and environment variable overrides for each of those things. So I think it's like a helper class. Got it. The guest stuff. I'll hide the last one. Yeah, get that sort of hierarchy of resource, system property, environment variable. I don't know. I'm not sure whether which way round they are, but yeah. So it's kind of a helper class for getting the data which is being saved by the user, is it? In the global, which are basically endpoints, which is being set as a global configuration for that verdict, yeah, yeah. Because while designing the high level of that particular module, I just saw this, like it is being used by so many places just to get the endpoint which is being saved by the user for example, bin step. Yeah, okay, yeah, thank you. And so Gareth, just for my benefit, that's a pattern that in my inexperience I hadn't seen before. So as you were saying, it appears to be bringing default settings in from a property file that's built with the package with the plugin and then allows the user to alter those default settings and it remembers the altered settings. Did I understand what you were describing? I think so, yeah, it looks like it seems to give a bit of a, so it's like if I'm looking at sort of one of the values, I don't know, AWS region for instance, it tries to load it from the configuration which if it sets that it returns that, otherwise it tries to get it from an environment variable. So it's an environment property, but I think environment property could be a system property or a environment variable or even a something in the resource bundle. There's a hierarchy and more. So it looks like there's like four places that it could, it goes to to try to look at these things one at a time. They presumably because it's looking at the actual system configuration first, anything that you've set in there is gonna override it. But I suppose it's there to give you kind of sensible defaults for all of the values that you'll need, which sounds good. Other like, I don't know how you would do that for a web-hop URL because we have no way of guessing what a sensible default for that would be. Yeah, thank you for that. And what's the purpose? There is a one class which is also, which is exactly look back, look back. Is it, is that term, is that, is familiar with Jenkins while making any plugin? Is it look back particularly, which is also being used? Yeah, look back, it's a looking framework, but I know that you can, use log back to send log of it, log messages to a HTTP endpoint. So I'm wondering whether that's what it is. I think it's just configuration properties. It's kind of a way of abstracting. Yes, okay. Garrett, just specific, in property loader.java, I just want to know the functionality of get build set, get build step endpoint. I mean, that function, what exactly that actually doing? I'm just unable to understand it exactly. There's a one function on line number 115, get build step endpoint. Maybe that's for me for that list to understand what is it doing? Yeah, so it's loading, it's doing that statistics configuration.death, which is a way of kind of like loading that global configuration class. Yeah. And that will be based on the Jenkins of XML files that it stores on the disk. And then from that, it's calling a property, get build step URL. So that's the particular property that it's getting. Now, if that has been set, it's going to return that. If it's not being set, it's going to go into that getEnvironmentProperty function. And that getEnvironmentProperty function, basically it calls to get instance getProperty and I get property and look at, it looks at environment variables first, I think, and it's resource models next. So that's providing and what you were describing earlier is the hierarchy of overriding, right? So plug-in defaults are lowest priority, it looks like. And then if I set something as a property starting Jenkins or in an environment variable to match this, it would use that instead. Did I understand that correctly, Gira? Yes, and I think at the highest level, it's whatever configuration you've actually entered in on the global configuration page, which it sounds like quite a nice sensible hierarchy of stuff for a little bit. It looks like a good pattern to use for this type of global configuration. I don't know if the Jenkins documentation actually goes into this level of detail, like global conflict. Not as far as I know, it seems like it looks like a very good pattern, it certainly does. Wondering if there is a recommended hierarchy of properties and overrides to use. I know different plugins have maybe slightly different conventions, I'm not sure what the Jenkins best practice is for that. Right. So just basically a hierarchy where people are just overriding and Jenkins is going to use that pretty good example. Yeah. I'm just correctly writing the high level so that would be the answer. Is there anything you'll want is, I mean, there's obviously that statistics configuration class. You'll want your own version of that and that will need to work with or you will want that to work with JCASC as well. So there are particular guidelines for making sure that that global configuration ends up in or is compatible with the configuration as code plugin. Any other questions, Segar? Or others, we're intentionally open forum here and we want, if you have questions by all means, don't be shy, ask them and let's have a discussion about them. One other thing I would recommend is to make this when you think you've got enough for like a first release or not even a version one release, but like it's enough to be growing out on a Jenkins server and you want to start giving that a go. I'm happy if you want to reach out and I can show you the JEP229 stuff that we're doing on the Texan client plugin where every interesting merge to master creates a new release automatically and that releases uploaded and it happens directly from GitHub. So it's quite nice. I like that. That's a very good idea. So just to reinforce what Gareth was saying, we now have a facility that is being more actively used in the Jenkins project where you can allow automatic release of next version of your plugin, next version of your component just by either using a specific label on the pull request that you merged or if I remember correctly, is it also tag dependent? I know labels will do it. All I have to do is do a label. Yeah, it's the interesting label. It's part of release drafters notion of an interesting category. So anything that's marked as a bug or an enhancement or a feature or something like that will automatically get a release created when that feature is, when that pull request is merged. And the reason that's done is so that there's not a large amount of churn when it comes to things like dependency updates or documentation updates or things like that. Olly can correct me if I've got that wrong, but I think that is what it's there for. So I am one of the fortunate users of that particular thing. I converted one of the plugins that I maintained to use JEP 229 and have been delighted with the results. I make a change that is irrelevant and it doesn't release it because I labeled it appropriately. When I want to release it, I just label it and it releases. It's, I didn't have to do anything more than merge the pull requests. And it's actually a very important part of the current community discussions because software delivery pipelines become a really important topic these months after the solar winds, hugs and previous hugs before. So in the case of Jenkins project, you also want to have a rock solid delivery pipeline. And then there are some opportunities for improvement. We can discuss into the previous contributor summit and we'll keep discussing in the future. Other questions. I have a question. So what if we repeat the today's session maybe as Jenkins online meetup for the next week? I really been doing a session at the spring of code for presenting Jenkins and contributing to Jenkins or maybe we repeat the same one as Jenkins online meetup without much additional effort. I like that. So the concept would be we host a Jenkins online meetup. I assume we would want to do it earlier hours. So roughly the time when we did the code for cause session earlier, so do it earlier hours and invite, how would you envision that? Invite panelists who are mentors or panelists. So basically what we were doing last year is at JSOC office house. So I'm at October 1st openings, et cetera. So having quick introduction and then waiting mentors to present their projects and having a long conversation. Oh, that would be fun. So Gareth, I guess this is a question to you then as a mentor, would you be willing to present something on potential, you're a potential mentor for Tecton client. I believe you may also be a potential mentor for cloud events. Would you be willing to present Oleg, are you envisioning like five minutes for two or three minutes, 30 seconds? How much time do I have to present the get credentials thing, for instance? Well, we can discuss that, but I think that means it would be okay, give or take. And then after the brief presentations of the project ideas, we would allow panel discussion or allow questions from the audience, is that the idea? Yeah. So basically the same how we were doing future projects at Hacktoberfest openings, hackathons, et cetera. So, okay, if I ask, so Sagar, Himanshu and Raghav, would you be interested in participating in that kind of thing? And would you be willing to bring your questions there so that we could answer your questions there? Yeah, sure. Well, it's probably- Yeah, for sure, no issues. In this case, because for those students who have already reached out to the project and who are working on project ideas who are reaching out to the seeks and potential mentors, for you, well, this session might be informative, but I don't think that it will be that informative, it's better for students who start later. Because historically what we have, there are a few dozens of students who reach out earlier and there are also up to 100 students reaching out in the last two weeks. No, but from what I can tell, usually almost every student who has accepted has reached out to us earlier. But still there is a high demand in this introduction, et cetera, and by doing online webinar, actually the rest of this topic. And I think that it will be the main target audience. I like that. I would love the opportunity to shamelessly promote why I think the Get Print Credentials project idea is the best project idea. Okay. That's perfectly fine. So, okay, we'll check calendars and schedule something. So I'm going to meet in 10 minutes when we can do it on Monday, Tuesday. Tuesday will be back. I'm out on Monday, but that's cool. Okay, Tuesday, Tuesday, so then I will find a slot. Yeah, and don't be shy about early. Given the number of students that we've got, I assume Saigar, Hemanshu and Raghav that you're all from somewhere on the Indian subcontinent. And therefore if we bias towards earlier in the day in Europe time, that's less late in your nighttime. It depends because now the schedules are crazy for everyone. So usually we're targeting evening in Asian and Pacific region because there is still study at this time. So we're targeting evenings. But now with COVID situation, it looks like everyone in the studies works full-time except ones who have babies. Okay, so on that note, okay, I will find the slot. Great. So any other topics or questions for today? Actually, I have a few questions regarding the plugin installation manager tool enhancement, like the issues which are labeled as enhancement. I was like looking into what I can work on. There was one issue, split CLI to subcommands and migrate to Pico CLI. Like I did not understand by what did you mean by subcommands? So plugin installation manager tool actually serves multiple purposes. So firstly, you can upgrade plugins. But also there is, for example, command to check for upgrades, just list available updates or for example, to print help, et cetera. And historically when these CLI interfaces include multiple actions, they tend to be over-competited. And actually plugin installation manager is a good example of that. Just a second, I can show it to you. Well, just need to close a few windows. Okay, I can screen share. Did you see my screen? Yes. Okay, so we go to the plugin installation manager code base. And currently if you go to plugin manager CLI, you can find that, yeah, there is CLI options class. And here you can find a bunch of different options. So some options can take to each other. Some options applicable only for particular use case. For example, node download, it's basically the flag which converts installation to dry run when you don't install updates. Or for example, the additional flags, et cetera. So what could be done instead? You could split it to multiple commands. For example, install plugins, check updates, let's say print help, verify plugins, stick, update, upgrade or something like that. So basically more atomic commands which take different arguments so that they're isolated and it will be much easier for engineers to understand this interface and to use it. Okay, like so multiple flags in one command, like flag, okay. Yeah. So like it's not yet implemented and that issue pertains to that. Like we, you want the command community wants to implement that, like more than one commands being able to run that. Yeah, because it also helps not only these business phases but also these qualities. So for example, I did the same conversion for Jenkins Cloud Run-up project. Yeah, I saw that your group, like you had also mentioned one Google group conversation. Yeah, I can just show you. Yeah, it was that. Yeah, this one. So here for example, what you can see that yeah, part from documentation and other things. So you can see that I split one interface to multiple sub commands. Like run CLI, list plugins, generate completion, et cetera. So it's also embedded into the CLI. And here for example, what I was able to do. So I had one mega class user configurations. I was able to split it to multiple ones. So basically there is beta encapsulation now and you can find half interfaces, pass them properly through the code and then basically the code working is significant there. So for example, here, there is a generic Jenkins Launcher command. It's command which takes the Jenkins Launcher options. So you can see that it's the abstract class. So basically I define the group of options and then every command which launches real Jenkins instance within the Jenkins Cloud Run-up, it just extends this class and then it basically gets all these parameters. So here, for example, run CLI command. So basically it's command which runs command line interface where you can interact with Jenkins for running into it. And you can see that basically it's just a plus name to be triggered, but all parameters are taken from upstream. There is another Jenkins Launcher command which basically takes the Jenkins Launcher parameter and it also takes the pipeline run options because it needs to run pipeline. And again, it's separate classes that put this much more readable and maintainable. Does it make sense? Yeah, like I actually I don't understand much about Jenkins file runner, but I understand what you're trying to say. Like you created something as my abstract classes and then you are extending that class into different files and creating different options for them. So it makes more intuitive for you. So basically I applied the object that I entered programming to the common line interface definitions so that they can be used easily. So Oleg, one of the things that I had not considered that I think you were just describing is that what are many, many very small, fine grained detail options today in the plugin installation manager tool would be presented to the user better as higher level concepts like download or upgrade. Could you describe some of those higher level concepts? Again, it was, I'm not sure I got them all. It was... So for example, it's all plugins. So it's basically the current behavior when you pass plugins.txt and installs the plugins you request. Also, you can just ask it to show upgrades. So for example, it shows you are available updates for your plugins.txt is related security issues. That's what we already support in this plugin installation manager. But also you can add a month which actually patches your plugins.txt without downloading files. Or you can add a command which verifies that the current plugin versions are compatible with the desired Jenkins core. So there is a lot of different opportunities for these to extend. But the account is very, very maintainable because in addition to these few hundreds that fit one's parameters. Actually, there is a lot of hope you need to go through in order to pass them within the system because you need to convert these parameters to just pass them between different invitations there. And finally, every request additional option becomes a kind of theme. So I can find a few examples. So for example, we know that for example, the plugin installation manager doesn't support proxies techniques now. And it would require several additional parameters. Okay, so here, add support for Jenkins version argument. So it's just example where you would probably want to just a few lines of code, but you can see that it's actually one kind of a secret. Because here, you have the additional option. Then I need to pass this option to configuration builder. It's a class in the plugin installation manager library. So you can see that there is a method which I pass to downstream. There is also getter method because it's used in tests. Then for example, here, special number can there is because I need to convert parameter to the right format. And then if you scroll down, you can see that the results configuration file in the library, which also includes special number, which you pass to constructed and then you extract it through getter. So that somewhere inside the code, inside the plugin manager implementation, it's fine that it's this version and does something. So all this chain of various codes you can get a lot of code lines, but actually it's the waste of time if you have proper interfaces. And if you can pass to them with the system by using proper SLI interface, it could actually achieve that easily. So Pico CLI comes into help. I have not used or developed anything in Pico CLI at the moment. So I don't know much about that, but it will come like it provides APIs to just implement that to get a higher level. Yeah, right. Okay, like I'll have to... Currently in Jenkins in the majority of components, we use library called Arc4G. So Arc4G is basically quite old library created by Kosike when he was working on parts and other projects. And while this library is totally relevant, it can be used, but at the same time, yeah, there are more libraries. For example, Pico CLI has a lot of advantages because for example, it's natively integrated to use Quarkus framework. So you can achieve much better performance in the cloud native applications with that. It also has more modern interfaces, et cetera. And when we were discussing what CLI library we want to use as a general recommendation in the community, we agreed that we would rather come with Pico CLI than Arc4G for new development. So Arc4G is still totally relevant. It's also a library. It has its own issues. For example, Arc4G doesn't verify duplicate parameters. And sometimes the conditions will be there, but Pico CLI is basically more advanced version of the library. Like I'll go into more details of how I can use Pico CLI for the library. Earlier you were showing that PR, there you mentioned one, like I have also messaged this to you in detail, but I think there was one line which you said using version number library. I mean, this is not much related to the issue as such, but it is related to the project. So I wanted to like work on this one comment that you had to do version number. Version number? Okay. Well, it was just on screen there. Oh, like... Yeah. It didn't help me. Yeah, it hasn't until version number. Right. So it's another library within Jenkins project. So why it's a separate library because we use it in multiple companies not only in the Jenkins core, but also in slide tools like plug-in installation manager, Jenkins infrastructure, et cetera. So it's basically a standalone library which has not that much quotes inside. It has actually just a few classes. So one is version number. It's a class which supports parsing version from different formats and comparing these versions so that we can see which version is newer, et cetera. So yeah, this is basically this class. And recently we added this email class of Java specification version when we were working on Java 11 support because Java hasn't been able to change in version formats. So in order to properly compare the versions and the operations with them, you basically have some additional code which can change the processes of the version which we've been using. Because for example, what we did some developers used to call Java 10, 1.10, and 1.10 is lower than nine. So standard comparison wouldn't work there if we were not normalizing Java versions hence at some point we added this class. But basically that's it. So it's just a few classes but yeah, it can be improved if needed. Okay, so I just, I saw a use of that. I thought maybe there's something to work upon some kind of minor issue type so that I can get going and contributing to plug-in and storage and manage it. Yeah, you can start from there. So there's number of library, yeah, there might be some improvements but it's generally really small case of code. So I don't think this is the real issues in this library process. So for this you can say that, hey, your Java version format doesn't support Java 17. I guess it doesn't. Yeah, yeah. Yeah, because when I was working on that there was no even Java 11. So you can do something like that but it's not a big need for this type of. Yeah, like not specifically to this library. I think there was some use of this library in Java, like not Java, plug-in installation manager. So I think there was something, okay. So were you mentioning, like you wrote a comment over there and were you like saying to improve this library not the plug-in instruction manager? I thought you were talking about improving the library, plug-in instruction manager, not version number library. Actually I have linked the comment if you can just go to the greater channel. I have linked to that specific comment. Okay. Not yeah. Yeah, I see. So it was today and you haven't seen. Yeah, I can understand that. You were in the spring. Okay. So this comment is about moving to version number. So basically, yeah, there is this class which seems to be generic enough. So maybe it makes sense to move it from this tool right inside the version of library. So that for example, if we specify version using parts for all the use pieces can be used from the library. But yeah, it's not like we must have conversion. It's just to document for the future for the use case for that. And again, this is for arts for G and if we talk about pick CLI, there is version number handler which is basically the same but for pick CLI. So for example, you could use this handler instead of the parts that are implemented for installation manager. Like I'll then I'll have to see the APIs of pick CLI like version. There's one issue which I do not understand at all. The issue is the add support for generating a new plugin file based on current Jenkins folder. It's in the plugin installation manager. In the project idea, right? In the GitHub repo. Okay, so for example, you want to migrate existing Jenkins. Not that one. Actually not that one now. If you can just filter it by filter the labels by enhancement like it'll reduce a lot of things. Enhance. Add support for generating. I did not understand this. Okay. So basically there is a Jenkins folder which includes plugins. So when you install Jenkins and you configure that as a folder which lists all plugin files. And what team wants here is to be able to read this directory and to generate a plugin list from there so that it can be played kind of to the operational scope. Okay, so generate a YAML type file of all the plugins that are there in the code. Exactly. So it's basically needed for migration. So when you move your existing instance to configuration as code, you can use these two and probably it could be additional sub-command which actually reads the directory and creates a file for you so that you just edit to SCM and can use it going forward. Okay, okay. Thank you. Thank you. One more thing if you still have time. Sorry, I'm taking too much time today. Continuing into the issues. Not in this issue. There is one more issue. The issue is add support for Jenkins BOM as a source of plugin versions when using YAML or text. Add change. BOM. Oh, yeah. This is created by me. So you have this build of materials. This build of materials basically provides cross-verified list of version plugins. So for example, there was a release 16 days ago and this release includes basically a list of plugin versions which have been verified against each other so that we launch the integration test, the functional test and find that plugins work with each other. You can see that there are some updates that are completed in this release. And the idea is that instead of specifying versions explicitly in plugin 64, plugin installation manager, you could refer this version so that plugin installation manager picks versions from this file. So basically you just use this file as a source of versions and do not define the text explicitly. Then if you decide that you want to update, you just say that instead of BOM version 26, I want BOM version 27. And then plugin installation manager does all the installation plugins you need. All right. Sorry if I come out as a new, but like BOM basically is a set of, what do you say, a set of two dependencies which are released as the new version of BOM. Is it like that? Yeah. So I can show you an example. Are you familiar with Maiden? Sorry. Are you familiar with Maiden? Yeah. I have started using Maiden. Me less. Oh, like I'm going to counter Himanshu's comment. I don't think I'm familiar with Maiden and I've used it for years. You should give a basic overview. Himanshu, no offense. I'm not trying to be offensive. I'm just saying that I was born with Maiden. So please no panic. Okay. So there is an example of Jenkins plugin, Maiden plugin. Here we have basically dependencies on multiple plugin versions, Java libraries, et cetera. And here you can see that we declare a list of dependencies. Some of the dependencies have expressed versions specified. For example, Java XML, the instance identity, et cetera. So here you specify the version expressed and this is the version Maiden will use. But for some companies, you can see that the version isn't provided. So for example, display your API plugin, JUnit plugin, maybe something else in this list. I'm sure. Yeah. For example, pipeline, et cetera. And here you can see that there is no version specified. So this version actually comes from the Bill of Materials, which is defined in dependency management. So here we use a Bill of Materials for Jenkins Core with line 2.235. So it's LCS baseline. And version 2060. Then when Maiden builds the plugin, it takes a list of dependencies from here. And basically you can do the same for plugins. So here you can see that and basically you can do the same for plugin installation manager. So instead of, you have an example, I guess here I still use plugins.txt. Yeah, so plugins.txt. So this is a file you can actually feed to plugin installation manager. And you can see that there are just 86 plugins I installed. And all these plugins have versions and it means that somebody would have to manage these versions. So if you go through the whole way, you just go through the list, the install updates, or you could use automation tools. So for example, here I use plugin installation manager to check for updates. So make file show updates. You can see that I just invoke plugin installation manager against this file and it shows me the plugins I need to update. And after that you can see that I have an automation. Or once there is a command which patches them for me automatically I could automate that. I have it automated somewhere else but it doesn't really matter. But it would be much more easier for me to say that instead of all these dependencies for the most of them I don't really care about which version. I just want the system to work. I could say that please take full of materials. So you don't manage it on your own instead of that you use this boom which is already across the file and for which you have some confidence that this plugin set would work. And you don't manage it on your own you just add the version of the boom instead of 30 dependency versions you just have one. Okay, okay. Now like a little bit more care about what's boom. Okay. So yeah, boom is literally bill of materials. It's not a software engineering term originally. It's rather a generic factory term. So it's just a list of all materials you need to produce. So basically the same software. Thank you. As one of the shameless beneficiaries of the Jenkins plugin bill of materials you don't have to do that. I'm not sure I'm all in favor of this technique and knowing about the technique eases the burden of people who maintain things. It's it's impressive how much benefit I get from somebody else checking that parts and pieces work together well and all I have to do is include that include that dependency on the bomb and all many good stories to show. And for the record somebody who is maintaining this session is mostly who will depend on the board and who Jenkins building is for request. Then somebody just approving them after everything passes. So this part is automated as well. So this means actually more work for the one who is like trying to find like trying to update from bomb and all that stuff. So whoever is wishes to go into this they'll have to do a lot of work. Yeah it is that there's a machine so a program that generates these proposed changes and the continuous integration process evaluates them and if they pass they just get merged. It's a very elegant thing. That is a reliable thing of course. Oleg can you repeat that part again like bomb how so there are thousands of millions of let's say softwares of how bomb is managing all of their versions and how they are fetching. Okay so bill of my details doesn't manage all hundreds of thousands of dependencies. It just manages the dependencies it was asked to manage. So for example here if you go to bomb latest let's see you have a number of plugins which we stopped. And for the record it's not all Jenkins plugins it's a subset which continuously grows but it's a subset of plugins and for each plugin we have a version and then basically we have dependable which verifies this file and just this one available in our description. But this is the specification you have. So it's not an offensive list it's just a list of what was added to the bill of materials. So is it manually being updated by somebody or is it automated process? It was added manually originally but the version updates automatically. So what happens dependable it's one of automation tools in GitHub at the moment it checks maybe in a repository and if it sees any available updates it submits a pull request. For example here's a pull request which was submitted five days ago it updates the metrics of the position point. Here you can see that there are some release nodes so there was a security peak so what happens with that? It depends about submits a pull request then Jenkins gets information from GitHub and starts the bill. And here you can see that the bill has passed so it was automatic and here you can see all the tests which were executed tests and test sets. You can see that everything is passing. So integration steps are hard to plug in and Jenkins versions if you need to see details you can navigate the Jenkins rub interface and give it so it's a bit hard to check but you can also see the results in motion for example. So we have a very cute 21 salvant tests from different plugins from different components and then when everything has passed Jenkins shows a green key so that you can see that we passed all the test series so so the mesh is currently manual well it's automatic but after approval we can make it automatic if you want but in our current case we still approve the request so I think the only job for maintenance is to just approve this request and mesh. That much of human touch is required to then approve this change. There is more automation possible you can find projects and even components and Jenkins which have almost full continuous delivery including automatic commercial and automatic release after that in the case of a bill of materials it's partially automated but the most tedious part is automated so just approving the change is nothing. I just want to say thank you to Mark and Oleg I know you guys are like keeping presentation from past I guess now to us thanks for Yeah exactly I wanted to see the same you guys are being pent up with this job Yeah awesome Thank you So I think we've reached our end I was going to go ahead and stop the recording thanks very very much everyone we'll see we'll do a Jenkins online meetup format next week and look forward to it now Oleg given the online meetup will we also plan to hold these office hours next week I think yes So we'll be here as well during office hours I don't know if you have any questions Great all right so see you next week everyone thank you and in the getter chat Bye