 Okay, we'll get started. So, hi, everybody. Welcome to Jenkins online meet up. Thanks for joining us in today's session. Geesaw, lead mentors will be doing an overview of 5 project ideas. And I will share those 5 project ideas in a little bit. If you're not speaking, could you please go on mute because I'm hearing some. Background. Okay, she runs. Can you please go on mute? Thank you. So my name is Alyssa Tong. I'm 1 of the admin for GSOC this year on this webinar with me are other GSOC mentor admins. Jean-Marc Mason, Chris Stern. Chris is also a mentor and then also Mark Waite is another lead mentor for our project. So, some housekeeping items before we begin this session is being recorded. We will share the link to the recording after today's session. We also have an active GSOC Gitter and discourse channels for further communication. So feel free to join the conversations there or post questions there after this webinar. And lastly, the code of conduct. This is in full effect here as well as throughout our community. So please be respectful and be kind to one another. So, in case you missed last month's webinar, we did a session on setting the expectations for potential candidates and tips on how to be successful in this program. If you missed that webinar, please use the link that I have there under recording and see, you know, are you going to be up for this and we want to make sure that you're successful in this program. So have a look and, you know, make sure if it's right for you. And then, so in this webinar are lead mentors who are Mark Waite and Chris Stern. They will walk over these five project ideas. The first three project ideas will be covered by Mark and the last two will be covered by Chris Stern. So, Mark, I'll let you take it from here without further delay, but for the remaining project ideas on the list, we will cover it at another day, which we will schedule soon. So more to come about that. Thanks, Alyssa. So one thing for my benefit is that you as participants in this session can be a big help if when you have a question you'll raise your hand. Now, the way you do that is down at the bottom of at least the screen I have, there's a reactions button. When you click that reactions button, there's a raise hand. And that helps the rest of us know, oh, you've you are interested in a conversation about this, then we'll call on you. We've got a lot of people in this session. And if we don't, if we don't use a some way of arbitrating, it gets really complicated. So please use the reactions button, raise your hand and then ask a question. But we do want you to ask questions. It's crucial that if you have a question, don't be shy, because if you have a question, several other people probably have exactly the same question and wish that they were brave enough to ask it. So, Mark, are you able to share from, okay, here we go. There we go. You should be able to share now. Great. Okay. So here we here. Let's sharing now and everybody should tell me if you see my screen. You should see a We background of something or other. Yes. Okay, great. So let me bring up. All right. And I see thumbs up. Very good. All right. So now let's bring up my my page. All right. So Let's start first with the where do you go to find this information. The first step is you look here on Jenkins under sub projects Google summer of code. All right. And on this page is GSOC 2024. And here is a hyperlink. That shows you where the project ideas can be found. So I just jumped to those and I want to talk first about And I'm talking about these in what I'd call my priority order. So, so as a lead mentor, there are things that are more important to me and things that are less important. So let's talk about them in my priority order. They may not be things that are as interesting to you, but this is what my priority order is. So the first piece for discussion is the back ending in extension index or tool. Jenkins is a large and long lived project. And it's important to our users that they be able to find information about it and that they, they get detailed and deep information. One of the things that we document for them is for the developers, we have an index of the extension points that are available from Jenkins plugins and Jenkins core. And this extension points, extensions point index helps them identify where they can add their capabilities. Oh, I could just use this to do that. I could use this. However, we have a problem. The tool that generates this thing is broken. If you look at this, it shows maybe if I were to give a rough count that might be 100 items in that list, maybe 50. Whereas there are probably four or 500 plugins that provide extensions. So this list is much too short and it's too short because of this problem. It needs to be reimplemented. All right. So what, what the story is, is that if a plugin has been modernized, I know this is going to sound terrible, but if a plugin has been modernized, it disappears from the list. And that's really a bad thing, right? We, we don't want modernization to cause you to disappear. So what we've got is the existing implementation looks like this in this repository. And this implementation needs to be revisited to consider how can we, how can we replace this implementation with something that works better to extract the back end extensions. Now, what's cool about this project is the way it does its work. It downloads all the Jenkins plugins and iterates over all the Jenkins plugins and should look inside their binaries for specific, specific Java objects, specific Java annotations. And that then flags, oh, this is an extension that should be indexed. And that exercise learning how to traverse large code bases and how to rapidly inspect binary data inside Java, Java files, Java binary files for me is a cool project. And that's what I think makes this one interesting. It's also a thing that's been broken for a while and we very much want it back. Now, to the group, do you have questions based on my description of the back end extension index or tool. And it's okay to raise your hand at this point, you could even just unmute and ask your question. It seems relatively quiet. We're okay with that. Jenna, go ahead. Yeah, I have. My query is that you said that back end extension index tool needs to be implemented. It means we need to be implemented in other way or just need to stick in the existing code. I think it would probably be a re implementation. So it will likely be a new implementation. Just because we've got a tool right now that already exists called the usage in plugin usage in plugins tool that knows how to download all the plugins and iterate over them. And it does a search inside those plugins for for things. And so that tool, the usage in plugins tool is probably the starting point for this recreation of this thing. It could be done by reworking the existing code. It that might also work. But my hunch is that it would be better to consider a full replacement. And the replacement has to meet the, the needs that were are already provided by the existing implementation. So this list of extension should still be there, plus many more. John, does that answer your question. Yeah, I got it. So you have a question from Carlos Carlos go ahead please. Yeah, Mark. Well, my question is where is it specified which kind of annotations we need to search or basically this part of the implementation that you mentioned before. Where are the good question and that's in the source code of the current implementation. So that's a that's a very good question. It's like, okay, where is it that this thing is defined and the answer is it's down here in the source code. So if we look here, we'll see, Hey, here is the here is the extension points extractor. And, and so it's right there in that implementation. Good, good question. Excellent question Carlos because right now what they're what doesn't exist is a formal specification or even a working prototype of something that says, Oh, this is how we would do that. It would be necessary to specify that like a formally so will be easier later. Right, I think that I think that that's part of the development of the project plan is, Hey, this is what should be extracted. And this is how it should be should be written. Yeah. Okay. Yeah. Now I have to I have to potentially refine this, I may be wrong on estimate of project size I've been wrong. Almost every time I've estimated project size in my life. So don't be shocked if in defining this you realize if someone who's working on this says, Oh, Mark's wrong. It's not a small size. This is medium or potentially even large. That's okay right me, me being wrong and estimating project size is a long standing pattern. Yeah, like every software engineer I think. Yes, yes, I'm not alone right it's a relief I'm not alone and being bad at estimating. Yeah, okay. Thank you. And if you come on these kind of findings. Don't hesitate and I recommend that you put that in your proposal and also document it and say for this and that reason, right, this is how I break down the work for the project. Right and and the reality is, is the project plan is the best way to improve this estimate right. For a real project plan is much better than mark make weight making a wild guess. Wild guesses just aren't nearly as good as real project plans. Good. Any other questions. Thanks. Thanks Carlos an excellent question very, very good. I don't see any other question. Okay, so, so let's let's look just just to remind people just how broad this is. Here's what plugins that Jenkins that I oh looks like. I'm going to show one little thing here which is 39 pages of plugins for Jenkins that need to be visited by this tool. And these pages I think it's roughly 50 per page. So, so there is, there are a lot of plugins that this tool will be traversing walking through as it assesses. Is there an extension in this plugin that needs to be indexed. So, oh Carlos question, go ahead. Yeah, sorry. This information and this binary is already storing some kind of database or file system or which kind of Very good question. Yes they are there. So we have we have an artifact repository that's the authoritative artifact repository for the Jenkins project. And that authoritative artifact repository is repo dot Jenkins CI dot org. And in the, in the tool I think in the source code for back end extension index or you'll probably see it. And you'd also likely see it in the usage in plugins tool where it asks a question of probably the update center and then uses the artifact repository to download the files that it needs. So it's a file system based repository. Okay, it well, I don't know how JFrog stores it at the back end because for me, it's a magic, it's a magic box into which I push artifacts and they bring them back to me anytime I ask. Yeah, that is important. JFrog you use for the artifact. Okay, right. Yeah, it's it's a donated donated JFrog artifact and we're very grateful to JFrog for hosting it they've they've hosted it for what 10 or 15 years for us and they're just very kind to do us. Okay, thank you. Any other questions on back end extension index or we're not done yet. This is this is just step one. Okay, so let's, let's shift our focus then to the next one which is bear token authentication. And this one is again an opportunity for Mark wait to hang his head and embarrassment and say that when I propose this project idea. I had what I thought was a simple concept for how to do it. Thanks to the explorations of several G Sock potential contributors, I've learned much more, and that that increased learning has said, Oh, wow, this is both more complicated than I expected and in fact, maybe almost infeasible in the in the way I had envisioned it. So let's let's talk a little bit about what this means. So bear token authentication is a form of authentication that uses HTTP protocol to share a a an authentication token between the get client and the get server for instance bit bucket. And a special header is used to transmit that bear token with a special format that special header is sent in the get command. However, that special header, then if we read the internet RFCs, advise that Oh, we should only send it once and gets already sending it. And there are all sorts of surprises and complications hiding in this thing. So right now the bigger challenge with bearer token authentication is to understand, is it feasible to solve the problem. And that is being being proposed here because the request from the users who asked for this was, please give us bearer token authentication so that we can talk to our GitHub server, using a, a simpler credential. And the answer right now that's being needs to be explored is, is that feasible is that and what is the right way to do it to fit with things like command line get J get get large file storage so get LFS each of them has some interesting complications hiding under this under this particular topic. This one I assume is going to generate some questions so so what questions do you have about it. And I'm okay if there aren't questions too that's great. I see your hand raised raised by Carlos Carlos go ahead. Yeah, well, one question related to the bear token. So, what is the, or how is the, how, how you are getting that token with the authority or who is the. Yeah, I don't know which kind of implementation you use for that to get these we are talking. Good question so the, the get plug in, or in this case the get client plug in has a very simple way of thinking about credentials, it asks the Jenkins credentials storage system, the credits Jenkins credentials manager to give it a credential by ID, and then it uses that credential and it's up to the user to create those credentials with the correct values in the Jenkins credential manager. So it's my assumption anyway was that this bear token is just requested from the Jenkins credentials manager by identifier and then pushed as part of the get request from get client towards the get server bucket or get hub. Got it. Okay. So, so now in terms of that doesn't put any constraints on the lifetime of that token right it doesn't put any that we rely on the the provider of the token to decide what's lifetime should be. And it doesn't put any constraints on how it arrived in the Jenkins credentials manager it could be that it's somehow generated and published automatically to the to the Jenkins credentials manager, the get client plug in just cares. I asked for a token by identifier and I get a value back and I ship it. So the issuer is this Jenkins credential manager, the issuer of the token. Either that or the issuer is the upstream repository and then it comes into Jenkins through some other means. Right. Yes, so, so the issuer from the get client plugins perspective is in fact, the Jenkins credentials manager. Got it. Okay. Other questions. All right. Oh, okay, well, go ahead. Thanks. My question is similar to Carlos. I was just wondering like, I guess the implementation for the bearer token identification is already active. So what exactly are we doing different. You may mention about making it simpler. What does simple mean. Good question. Okay, so that that's worth some some background on the get get client plug in authentication alternatives. So the get client plug in speaks to protocols. It either will speak to the remote server using SSH protocol, or it will speak to the remote server using HTTP protocol. When it speaks to the remote server using SSH protocol, it must use a private key. All right, so that's a private key type credential, something you and I would use when we run invoke an SSH command. Those are private keys. SSH private key is used for SSH protocol based communication. When the get client plug in today communicates through HTTPS with a an upstream server like GitHub or bit bucket. It uses username slash password credentials. So the username slash password credential is a different credential type in Jenkins than the SSH private key credential type. What this the idea here was we would add support to the get client plug in for one more credential type instead of just SSH private key and just username password. We would add secret text type where secret text is just a single string and that single string would be what would be pass as the bearer token. So the idea there was instead of two credentials system two credentials being allowed SSH for the SSH protocol and username password for HTTP. We would allow three where SSH is required for the SSH protocol, but either username password or secret text would be used for HTTP. And it would be up to the user to decide which credential they chose and that would then let us choose that type. So Okawama, did that answer your question? Yes, yes, it's very close. I think it's clear now. Okay, good. Yeah, and there's actually a pull request pending that proposes to add the support for secret text. However, the technique being used I guess this is another one where it's worth maybe it's worth highlighting this to everyone here. There is a pull request that proposes Hey, here's how we could add support for secret text and do this bear bear token authentication. The problem is that proposed pull request assumes a version of get which is newer than the versions that we support. So this is one of those oh flinch because some of my colleagues in the platform sig know what mark weight feels about certain old operating systems. Red Hat Enterprise Linux 7 is not my friend, for example, but Debbie and 10 and Ubuntu 20, both ship a version of command line get that won't work with this pull request that's been submitted. And I would expect whoever proposes this project must propose a solution that will work with these older versions of get we simply cannot abandon our older or our users on old operating systems if the operating system is supported by Jenkins we owe it to them to keep supporting it. So it that that is a technical difficulty hiding in this project that you don't just have to think about the version of command line get that is running on your windows machine that you just barely installed. You also have to think very carefully about the command line get that is installed on mark weights Debbie and 10 box that he installed originally three or four years ago and is still using and keeping updated. So, so that's a that's a be safe and be aware. Any other questions on bear token authentication. Okay, you've been very patient let's talk about another question. Oh, go ahead. Oh, okay, well, okay, okay, model. No, I was giving it thumbs up. Oh, great. Thank you. Okay, super. Thanks very much. All right, we're we're we're we're I've used more time than I probably should have so let's get to the next one the plugin installation manager tool. Okay, so the plugin installation manager tool is used by people like me who construct Jenkins controllers with configuration as code. And we define the list of plugins that we want to install. And then the plugin installation manager tool downloads those plugins and makes them ready so that I can create my new Jenkins controller based on it. We use it in the Jenkins container images with Docker. There are users who use it outside of that for instance with a standard installation. It works really well. However, it doesn't always meet every need. And the challenge then is that there are some things that need to improve here. And those things that need to improve are you're invited to explore them to understand them. One of them for instance was discovered or discussed in depth at the Jenkins contributor summit in Brussels, Belgium, February 2 2024, where we need a concept of a lock file in the plugin installation manager tool with that lock file being a precise list of exactly the plugins we need, as opposed to the high level definition of which subset of plugins are most important to me that is used to generate the lock file. That's one. The other thing that we need from this particular project is Bruno and I right now are suffering because of a bug in this project. And that suffering is causing us to wish somebody would please fix that bug. You can find that bug in the list of issues. And it is that we're not resolving trans transitive dependencies correctly. So, so there's an interesting problem in graph theory hiding there. And this one needs your help. Any questions about the plugin installation manager tool improvements. Hey then Alyssa, I think we're ready to go on to Chris. I'm going to go ahead and stop sharing my screen for now unless there are there are questions. I am sharing my screen right now. Hey Chris. Me. Not there yet. Yeah, it's kind of weird. It seems like I'll stop. Back so. I'm sharing and sharing again. Hold on. Now that now is this the right slide now. It's still locked on shows Alyssa is starting a screen chair. While we're sorting that out, I see that there is a question there from Jana. Can you go ahead. For a single project idea, how many people can contribute? Because you asked that again for a single project idea and then I lost the last of the sentence. Yeah, for a single project idea, how many people can contribute. You explained that Mark or do you want actually I'll leave it to you john mark or to Chris so. Yeah, okay. So, several people can compete. On one proposal or on one project idea. Only one person will be selected or a given project idea project. And this person will then be sponsored by Google during the summer to do the work. So, many people can compete only one person will be selected. And once selected, there will be only one person working on that project during GSOC. Does that answer your question. I don't want to take we can we can take these kind of questions at the end of the presentation we want to focus right now. From Akash in the chat. So, oh, I want to take a look at it and answer it because it's it's where to project. It's not a general question. So we have to plug in. You see it mark. I do see it. Okay, so let's let me see if I can give an answer. So how many features or enhancements can you propose as many as you feel will fit inside the time of the project. Remembering that project plans are are a best guess and propose several. I would not see any any shame in proposing a set. In this case, the most crucial ones, the bug fix that I want to see is a good way to show. Hey, I know how to work on this code. So you could even fix that prior to the prior to the release prior to the decision on which projects are being selected. There's an additional question. Oh, sorry. Oh, go ahead. What's the additional question additional question. How, yeah, follow up question. How will they be prior to rise. And I can answer that one is you propose so the candidates says, in my opinion, this is the order which I would like to tackle the different features. So you build a project plan. You can discuss it. People will review it so the mentors will say, well, my opinion for that and that reason I would change the order, but you come with a proposal. Don't forget one of the ideas behind Google summer code is that you, you're not going to do what you're told to do. You are in the lead, you are proposing things and we're just there to help you achieve that. So it's, it's a different relationship than at school, where you have to do what a teacher tells you to do. Does that answer the question, Akash, waiting on the. Eventually you can come back. Yeah, okay. Thank you very much. Being mindful of the time. I propose or suggest that we move to Chris presentation, and that we keep the remaining time for questions. Sure. Go ahead. Next, I'll talk about the implementing UI for Jenkins interest statistics project. It's supposed to be a medium sized because like Google just introduced three sizes this year. So used to be like this one was called the standard size last year. And the project difficulty is intermediate. It's, if you're a beginner, you're welcome to try to try to if you're capable so project nature is more in front end web development data visualization and presentation and maybe a bit of data wrangling to the goal is to build upon the current guitar pages base to UI into user friendly and full featured website for showcasing Jenkins interest statistics. So, this means that this project has some market value for Jenkins because like we can use it to to to get more sponsorship from interest parties. And it's may be why it could be like a potentially a good project to voice for because like it's kind of important to Jenkins. Skills wise, we'll use mostly react. So, either invites of it or gets me. So it would be probably in JavaScript, we might consider typescript but I don't think it's worth a hassle because I for if we do in typescript it may take longer. And I, it may take more work to get done properly. And also we'll be using pun libraries like Apache, each hot or plot need address, depending on like what the contributors preference and so. So is there any questions about this project. I just answering a small questions from Carlos in between so oh no we're we're going, I'll answer to you Carlos afterwards but first. I can't read rattle. I hope I don't butcher your name. Go ahead. Hello. Yeah, so after saying the code base, the first thing that I noticed that the number of Jason and CSV files are a lot. So I was thinking that to use a database SQLite database maybe, you know, make an API and fetch the data from there. Because it's said this way because like, I think it's like for security issues as well and on top of that, like, the infotainment say that that's the way they've been doing things and it may not be feasible to ask them to change the way things and we probably won't have access to pose rise surveys to fetch it from. So we have to work with. Yeah, hosted. That may be a limitation, but that's also like that that maybe has advantages to it too, because they got it's. In a sense, more stable. Okay, and one more thing I think I asked this in the chat, but that the part of the count of plugin per Jenkins version. That's actually hard coded in the website, in the GitHub pages, right for every file there is an HTML every plugin there's an HTML file hard coded and the data are hard coded. Yep. Okay. Let me try fun. We're looking at what you're talking about it's because I already found it so you mean in the way but right. Yeah, in the report. That's, that's, do we still remember which part of it is, and is it in test data. Yeah, let me see once. Yeah, inside the plugin versions folder. Plug in versions. I mean, I see it. Okay, just Yeah, you will see there are a lot of HTML files and each HTML file has the data of each plugin will hard coded into it. Okay. Like, do you have the power of what you're looking at? Can you share it with a chat? Share. I don't think my network will hold if I share. Oh, okay. Share a link via the chat. Yeah, just paste a link to the page that of concern in the chat system. No need to share your screen. Yeah, okay. Wait a second. Okay, let me see. I think like these. We have to, what was it was exactly a question you mean like for which file. Yeah, I'm basically asking in order to make it dynamic right we should make it dynamic if you're doing it in real instead of hard code. We have to replace all this. So we will have to replace all these in a wax. Right. Yeah, we have to make it into JSON or CSV file set for each plugin. I think they already have. The CSV. They have it. They have it but I didn't see it in the repo. They're generated and not hard coded. Yeah. Yeah, and one more thing I just made a demo web application to just see where it goes. Can you guys check once. Okay, so again, so where do you get that info? Yeah, sorry. What what do you say. So because I didn't catch like every word. Yeah, I was saying that yesterday I was like thinking how to make the website and stuff and I just made a demo website so would you like to review or something. You can post it in the chat like on Gitter so we can have we can all take a look. So all of the mentors can take a look because like when we do ranking all of us contribute not just one not just not just four mentors for the project or the lead mentor. Yeah, I didn't catch on. Can you repeat once. So the what Chris Chris is saying that these demos you can share in ask people to review it by sharing the link in the Gitter chat. But definitely you should hold on. But definitely you should mention them in the links to that in your proposal. So you the written document where you will describe what you're going to do and why we should pick up you as a. Yeah, right. And on top of that, like every mentor within Jenkins we evaluate every one of the projects. So like you may want to like, you may want more people who get to get a look get to take a look at what you've done. Depending question from Carlos and Chris how much time do you need for your last project. Should be quite short. Okay, we can go with a question from Carlos. Yeah. Okay, go ahead. Yeah. Sorry guys. Well, the question is I'm seeing the code so basically this project is to migrate from the jQuery version that you have to react. I'm mistaken or is to migrate from is like from the current GitHub pages version to react version to full version. Exactly. It's not very well designed. Yeah, because I'm seeing that you're using jQuery for the components so. Yeah, I see in the code. React. Yeah. Okay. Yes. Okay. And also another question is, do you have environments to test this if we do some coding just to test the resolution or how, how do you do that? It's saying the back and already the front. How do you. Manage that you have. Yeah, if we're back ends like that. There's a way to get the data. So I will let my co mentor talk about like later maybe on GitHub. You can ask him, then his name is Harvey. So if you ask the question, he will you monitor the channel. He'll know it. So you answer. So that's basically just to. Yeah, he's in charge. He's in charge of the info part of the project. Okay. He definitely knows. He knows where, where to test and set. Okay. Okay. Thank you. Yeah. And so, Carlos, the working assumption is build locally generate a static site so that we can see it. It's not nice. It's, it's much healthier for all of us. If we can do a local build. Rather than having to rely on. But I'm talking about just the front. Yeah, the front that we can do it locally. Yeah, you can create a docker container for that. But I'm talking about the backend because you need to access the file system or the repository. So, yeah. Yeah. And I think even there, the simple approach I've seen is. Download the data files to a local copy and reference them. Okay. Got it. Okay. Got it. It's mostly because if you want to see maybe improvements, let's say in the searching party in the, in the backend. Yeah. You need, you need some amount with amount of data to see if the, the change that you did basically is. Performance or not. So. Yeah. Basically is that. Thank you. Okay. So next one is improving plug in have score scoring mobility project. So it's same as last one of medium sized. So we, but it may be shorter than one in a certain five hours because it depends on how many, how many, how many probes you're going to add. The project difficulty is ranging from beginner to intermediate because it doesn't require like to like our knowledge, but we do require you to know some basic OP is Java to complete the project. Project nature. So plug in have score attempts to provide an accurate assessment of how much can help a pocket needs in its current state and can be used for every interested potential contributor to have an in depth look at how they can fulfill those needs based on expertise. This means that like it offers kind of like some metrics to user or contributor to decide like how much work they need to do to work to do on it to make it to make the plug in the functional one or to restore itself and make it like have a very good have school. So also allows users to make a conscious decision before installing and using a parking. So it's as is like for as reference with the users. So if if the health score is kind of low, they may consider not to install parking or uninstall it all together. And the goal is to add some additional probes to your scoreings to the parking house project. So we do have a cone. We pull for it is called parking health scoring as hosted within a thing within Jan's info and the skills to be gained or developed through these projects are Java OP data extraction and GitHub repositories. There is realization and lessons. And then we do have like some suggested probe ideas and plug and have scoring repo as well in the issues tracker so we may want to take a look if you're interested. And I think that's about it. Is there any questions about this project. We have already one from Carlos. Oh yeah. Yeah. So, so the, sorry, so the, the scoring part is already defined in the, in the code, right? How do you score or how do you define which is a health score for a plug for it. If you have more probes, you have to refine the formula to. Actually, it's necessary to define that part like a specification of something to decide when we'd be. Thank you. So, so Carlos, what I would, I would phrase what you just said slightly differently. The health score that we have today is a good health score, but we want to improve it and some of the improvement may be changing the scoring system that's being used adjusting weights or adjusting values that are being applied. So the measures might be adding new, new tests, new checks for this or that measure of health. And again, again, in order to include those in the score, they'll, that will require that the scoring system be adjusted to include them with an appropriate weight. Okay. Also, the idea of that health score component is to have an API for that to be consumed. Oh, it's much more than that. So, Alyssa, is it you sharing your screen. I am. No, no, no. Well, you could either stop sharing or we could have you navigate to plugins that Jenkins.io. This is something I think it's worth showing people how it looks. Yeah. So if you if you could just open plugins that Jenkins.io. My computer is. It's still alive because we see it flickering in your glass. No, we cannot see you're joking. I'm joking. Well done. I'm getting there. Or, or Alyssa, if you prefer, I can share my screen either is fine. There's no, this is not, not something that it has to be you driving. Perfect. Okay. So here is the site. This is plugins dot Jenkins.io. There are by now almost 2000 plugins for Jenkins that are presented on this page with that many plugins. Jenkins administrators confront a very real problem. How good is this plugin that I'm considering installing should I actually install it. So Alyssa in the fine plugins field let's have you type in how about the word platform let's see platform is that a good choice. Let's let's yeah let's pick one get get is okay get is a very very reasonable and it's the most popular search term we're not adjusting the search. Okay, on the top left set of tab of cards you'll see in the card section get the top left most card that one click it. This is the Jenkins get plugin page. It's got all sorts of useful information pages and pages of documentation, etc. videos embedded la la la la la. All the way back up to the top Alyssa because we want to look at one of the other tabs there are five tabs across the top. So releases tells us what are the plugin releases that are available, and their change logs issues don't click issues because we don't want to wait. The get plugin has an embarrassing number of issues open on it dependencies tells us what are the things on which this plugin depends and which plugins depend on it. And the last one, the most important one for this discussion is health score. What you see here is this plugins health score is 99 out of 100. And the thing that lowers its score is in that nice highlighted section down below repository configuration. What this project is proposing to do is further improve this. So Alyssa for instance you could expand any one of those down arrows on the right hand side over by the 100% on adoption. And it says, Oh, here are the details that this score was applied to the plugin is not up for adoption. And it's been released fairly recently. So it didn't lose any points there. This site is what you're trying to improve. And yes, we do back end assessments to help us contribute to the site but ultimately we're presenting to users Carlos did you have a question there. That actually is clear. So, so basically with this, you can, I don't know, like, decide or define a which plugins needs to be. Yeah, the people to work on or something like that. This is one of the indicator that it gives the other one is when you're administrating Jenkins is instant and somebody of your team comes a I found this nifty plugin and I would like it to be installed or with the administrator can have a look and see there is this well maintained has it been released recently and so we have a couple of probes that give this picture and worse continuing to improve that. So the, for example, it's much better if a plugin has was released within the last year, then if it was released nine years ago, and we have plugins that were released nine years ago. So, so it's it's good for users to know, oh, this is current it's also good for them to see the list of maintainers on the right hand side there that hey there are multiple maintainers or if there are no maintainers that gives them another hint. Yeah, or if he said deprecated also to take a right deprecated is another one or open security vulnerabilities. It's all good contributors to health score. And it's we like for our users to know about those kinds of things. Yeah. Okay. Yeah, clear. Thank you. Chris was there anything else you wanted to highlight in terms of the screenshot the pictures. No, but maybe can we go also to the report itself to the plugin. I have scoring repo in. Yeah, that'll be a little more complicated Alyssa so so under the under the links under the links on the far right hand side there's GitHub if you click that that gets us to the repository for this plugin. I'm going to rewrite the URL. And I think it's well actually, Alyssa maybe I'll just paste it to you. Yeah, because I think it's isn't it called plug in site or plug in health score. Plug in health scoring here we go. So I'll paste it into the chat Alyssa in case that helps. Yeah. So, whoops, where is the chat. There we go. Here we go. So here is the page and this is the contributing page for if you just click that link. It'll take us into the right page. Contributive page. We can take a look at that. This. Are you able to so I pasted I pasted it into chat but we're currently seeing your get the get plugin page. It's not sharing. So now I have way too many things. Hold on just a minute. Perfect. Yeah. And Chris was there something specific you wanted to show I just took her to the contributing doc. So if you can like we can go through it quickly. So if you want do want to contribute to this project we remember to go to this page first to get like to get like the basic info about what to install and what steps to take because it can get kind of complicated and kind of confusing. 100%. Yes, actually I think this component is quite important because it's to keep basically a healthy login ecosystem. So, yeah. Right. Plugins are is the power of Jenkins. Yeah. But on the other side to manage or give clear indication. Well, yeah. It's like when you go to a to a restaurant or or self service you want to know if the food is good goods or or is too old. Yeah, the reviews right on the right. At least I can we go up top to the issues tracker. Issues. And maybe click on just probe. Just just click on the chip or whatever you call it. Click on. It's fine. Yeah, just click now. So I can see like all over here, especially first bill by Adrian. Those are the probe ideas that we currently have for for the GSoc2074 project. So, but you can always think of new ones. But the issues want to like the thing we the things we want to consider are like objectivity, how useful it is. And also like how accurate the measure can be. So like, so yeah, go ahead. Yeah, yeah, I was thinking that maybe the rules that maybe needs to be reviewed because I don't know what are the measures that you are taking maybe number number of commits the last month or the number of the number of downloads, or yeah, I don't know. I'm not I'm not sure about a number of downloads that it may be, it may be like a good measure, but not not like a very objective measure because it's a kind of popularity to is like, on top of that, like, it can be downloaded more because like there might be some issues sometimes. So that. Okay, so this is the indicator. Okay. Yeah, so we need to find like good indicators, good, good key measures, you know, to determine like which new probes to add. And it's like, we have some other suggestions previously and they were not good and retracted them based on some reasons that like they may not be like very accurate and reproducible. That's why we don't we have to be very careful we can see which probe to add. Yeah, I think guys, a matter of review the rules and maybe try to add more meaningful ones but that's good. Yeah, meaningful ones. Yeah. So, Jean-Marc, you have a question. Yes. Well, I don't have a question I have a comment because we're reaching slowly the top of the hour. I'd like to make a general comment here. So, GSOC at this stage, and we're still waiting to know what are the organization that will be selected. So, but in any case, sort of the rewind, take a deep breath. Sorry. A lot of people will compete, will work on a proposal, get interested, and will try things on. Not being selected does not mean that you need to close everything, forget it, and so on. What I would like to advocate here is saying that the work that you're going to do and the preparation, even if not selected, is worth the exercise. And I encourage you also to continue for the fun for two reasons. And the most important one, this is the best way to learn how things work, how to contribute, learn what others did and you're building on their shoulders. And this is a very important way to grow. I agree. This is a competition and there's nice pocket money to earn with that. It's very, it looks very good on resume. But it's not the only thing. And learning how to contribute, how to participate in a big project and being proud that your code has been merged and is being used by thousands of people. Just that is worth doing the effort. So don't do it only for winning and be part of the team that will attack the summit, the picture of the mountaineering in the beginning. You can still learn. You can still have a lot of fun and also give back to the community by participating. I just wanted to share that insight. It's a competition agreed, but contributing, participating. And I heard with a question a lot of people get excited. Oh, this is interesting. This is interesting. And so don't refrain yourself. Just participate to it, learn. People will be around maybe in other forms to help you. Maybe not the same pace as GSOC, but the community here is welcoming and everybody learns from these parents. So I'll stop talking as an old man with white hairs, but just very interesting and useful things to do. So yeah, so we're out almost out of time. We got like less than a minute, but as I mentioned earlier, I will send out the slide and the slide deck and the recording to this meeting shortly. And then we still have the remaining list of project ideas that we will cover with you at a later day in time. So I'll probably try to schedule that for next week. So keep an eye out for that. But otherwise, keep the conversations going and get her and we'll talk soon. Bye. Thank you everybody. Bye. Bye. Thank you for your attendance.