2026-08-20 GSoC 2026 Final Presentations

Okay. >> So, I think we are on time. Chris, I think we can start. >> Yep. >> Uh, all right. So first of all uh thank you so much to everyone for joining today's session and we are really excited to uh go through all of the presentations um around the projects that were built by the mentees for the the Google son of code 2026 program and it's great that we were able to accomplish a lot over the past few months and a lot of open source contributions being made into the genkins ecosystem. So we are super excited to showcase the work that has been put together, the hard work that has been put together over the past few months. Uh and each and every mentee will be given 10 minutes to present and we'll have a couple of minutes for Q&A. So if you have any questions about the work that has been done by a given mentee, the agenda has already been shared on the zoom chat. So you can take a look at the order and uh yeah so we'll continue. Uh a quick introduction about myself. So I'm Shaya, one of the org admins for uh Google code for genkins this year along alongside Chris and V. So all three of us uh have been involved that and then of course all of us are also part of uh the mentorship group for the different projects. So as we will basically talk about each and every project, you can also take a look at uh the mentors of that particular project. Uh but yeah, with that we'll kick it off. So uh we do run these genkins online meetups. So these are completely communitydriven virtual meetups uh which you can join. There is in fact uh the meetup.com uh where you can find whenever the next meetup is basically scheduled and here uh we generally talk about case studies and success stories around different plugins and the larger Jenkins ecosystem and we're always looking for speakers. So if you are a contributor or you are using Jenkins in a unique way at your workspace, we would love to hear more about uh success stories around the usage of genkins in production use cases. So you're always welcome to apply for these. And a lot of these are recorded so you'll find recordings on YouTube. And for those folks who are new, so of course uh Genkins is one of the most well-known open-source automation servers that are out there primarily uh used for CI/CD. Uh but of course apart from that uh if you are like building a multi-stage environment where you need to have like development build uh build stage or development state production stage all of that is made very easy with the help of Jenkins uh to do end to-end deployment and testing of your software and historically it has been used by a lot of large enterprises as well and uh as a Jenkins community we are one of the most active open source communities and one of the longest running open source projects as well. uh in fact the main bulk of through of open source contributions that we get from our community is through the large ecosystem of plugins. So these plugins you can imagine plugin for AWS plug-in for let's say Microsoft SMTP. So uh whatever you can think of where you might need a CI/CD integration you'll find a plug-in there and you can always contribute to the plug-in ecosystem as well and we have contributors from all over the world. uh we have been one of the most uh longstanding uh organizations within Google of code. So I've been very uh you know very lucky and we are grateful to uh the Zox program for continuously getting us on boarded as one of the uh projects and one of the organizations for such a long time and of course uh through this program through today's uh session uh hopefully you will get inspired to be able to make contributions back to Zenkins and of course the Zenkins community is always very welcome to open contributions and accept new ideas and suggestions that you might have even outside of Google Son of Code. And uh this session is getting recorded. Uh for Q&A, you can use the Zoom chat. Uh we also have a couple of other things. So we have our official Zenkins uh Google code gitter channel that you can find on matrix and we have linked the link here. And after the meetup, you can either join the discussion on git or on discourse. And uh of course do ensure that given the fact that this is we are meeting online but you still have to uh respect uh and follow the code of conduct. So please do ensure that you do follow it. If you feel that someone has violated you can reach out to one of the org admins myself Chris or we and we'll take action from there. Uh so today's agenda so you know we'll give a quick overview of uh Zenkins in Google of code 2026 and then as I mentioned earlier that we'll have project demos from all of the different projects that were selected and uh then we will be having Q&A and every uh contributor will get 10 minutes to present what they have built and a couple of minutes in addition to that for Q&A. Um so great thing was that as I mentioned we have been very lucky uh and uh you know very grateful to uh the Zox program that this is our 10th year in Zo and uh it's a great feat because a lot of times you know sometimes um some organizations might be there for 5 years and then for two years they're not there. So we are very lucky to have been here in the 10th year running and for GOC for 2026 we got five projects that was selected. Uh so we had the AI chatbot to guide user workflow from uh and for this Daniel was there uh as a saw contributor. Then we had u continuing our uh AI powered chatbot for being able to quickly access Zenkins resources. For this we had Malikin as our contributor. We had another one which is Zenkins email notification using Outlook SMTP with authentication. So here we had Muhammad as our GSO contributor and then plug-in modernizer stat visualization with Pratik. And finally the retooling of the genkins uh IO website for showing like the success stories and uh for this we had as a Gog mentor a mentee. So you can see that you know a lot of these projects are new but a lot of them are also like plug-in based. So this should give you an idea like on what kind of projects we typically get uh selected for GOC and um through you know today's program we'll also understand um and you can always reach out to us if you are interested to contribute or you're interested to suggest projects we are always welcome to accept those suggestions as well. So with that we'll kick it off and again uh just a reminder uh please use the Q&A uh chat the Q&A section within the within the Zoom chat to ask questions and of course we'll give dedicated Q&A time after each and every presentation and at the end of today's session as well. So we'll kick it off with uh Daniel who will walk through the project that they have built which is the AI chatbot to guide user workflow. So I'll let uh Daniel take it over. So Daniel, if you want to probably share your screen. Uh, okay. So share. Okay. Oh sh would you like to share your screen so um you can come to the slides while Daniel talk. >> Oh yeah sure let me give us any okay sure. >> Oh sorry >> is it visible? Okay. Yeah, perfect. Okay. So, I I'm Daniel. I'm a second year Italian computer science student at University of Camino in Italy. I'm a passionate developer and an open source contributor. I've started contributing this year to Jenkins and I'm very happy to be part of this community. You can go next. Okay. So this year uh in this summer I've de developed a new plug-in which is an an AI powered chatbot and which is powered by an agent and this chatbot is very helpful to both um starters in with Jackins which so can help them in maybe configuring or navigating in Jenkins for the first time but is also useful for experts that maybe needs to troubleshoot some failed build or has some problems with the Jenkins environment. Um you can go next. This is the general architecture of the of the plug-in which actually as a plug-in front end which is displayed in the Jenkins UI as a panel where the user can actually interact with the chatbot, upload the context and create new chats or also see the all the the chat history of the previous conversations. And the front end um communicates with the back end by passing with the by using the Jenkins controller which actually validates H request and actually secure the connection between the two. In the fast API back end, we are using a langraph which is uh the framework which uh power our agent and the the fast API back end is connected to a postgraq database where we store uh the chat history and that's also a coolant vector database where we store all the information vectorized so the Jenkins uh documentation the the plug-in documentation and also some uh discourse topics. and ready threads. And finally we uh our agent is powered by some agnostic LM. So actually we can pick uh the LM we prefer from the provider we prefer and connect it with our agent. We can al obviously also uh open source models by using or maybe using third party API from cloud providers. We can go next. In the phase one of GSO, I've created the general architecture which empowers our plug-in. Um uh initially I've started with scraping the with with creating the logic which scraped the Jenkins documentation the plug-in documentation and the Reddit and write topics and after I've developed the first API back end uh and I've connected to it the database and postgra square and I've implemented the arbit retriever which actually uh use both um dense uh model and a sparse model and I've de developed the front end UI which is uh which is built with the react plus vite framework and finally I've implemented the jin jenkins controller logic which permit the connection between the front end and the back end you can go Next in the face I developed logic which actually reveal the the [clears throat] context um information from the from Jenkins. So uh the all the information for example related to builds uh jobs or the system of the master and and the nodes and I've also developed the tools and this the agent logic which actually is the core part of our plug-in. uh our system also has a pos uh the possibility to en to enable ranking or with the IB drivers. So we can actually uh have a model we we can actually use a model which um rank all the results from the ret driver and takes the most relevant and I also implemented the contextual retrieval which is a technique created by entropic for um improving the the the retrieval um for improving the retrieval uh technique. And I also implemented an agent an agent on demand workspace infection which actually uh give to the agent the possibility to retrieve a file from the workspace and analy analyze the content and also decide if maybe a specific error happened at in that in a specific file. Um after after I I implemented the the evaluation of the agent using deep evil and we using four different benchmark uh like faithfulness and relevancy context recall and cost and tokens used. And finally I also implemented observability using both lang and langu. And the uh user can pick just one of one of them if it wants. You can go next. So all good. But what the agent can actually do and you can next. Okay. So for example, this is a video of um the agent and we can see a failed build and we can actually upload the context by clicking the but the button at the bottom right and asking why this build failed. And right now the agent is going to check the logs and and seeing if there's a specific logs which can help. And after after that it's going to check also the genetics pipeline and see that there's actually a command which requires a plug-in that it's not installed and after that actually answer to the user and give him some means on why and how to solve the actual problem. Also, as I said, the agent can thanks to a specific tool which is get work workspace file can actually retrieve a file from the workspace and see what's what's inside. In this example, we're asking him what's inside the primary config JSON file and is answering and is before e before fetch the three of the wall workspace see where what is the path of the file that we're interested in and after use this other tool to fetch the content. You can go next. And finally, um, the agent can be, as I said, can be also very useful for starters, which may need to navigating in Jenkins and also configuring him. For example, here the user is asking what how can I install a new plug-in? And as you can see the agent is also very helpful for the start for starters in Jenkins. Um you can go next. Uh about the journey during this time I I interacted and collaborated with my mentors and they give me very useful insight and and advice. I learned to work on complex project and it it was very wonderful to see how actually for for for the first time how the open source world works from the inside. You can go next regarding uh future plans for the plug-in and the project. I I will in this last few weeks of extended per period I will improve the documentation and also implement end to end testing with containers to the future contri contributors I suggest to implementing mark markdown support on the on the UI so that there will be an nicer UI and more readable and also implementing human in the loop features so maybe in the future The the agent will be able to maybe toggle toggle some settings for the user and also maybe other things without the need for the user to actually do it and letting the agent do it directly. You can go next. So if anyone has some question I very happy to answer it. Um >> feel free to either uh raise your hand or if you want to like ask in the chat as well the Q&A section you can uh feel free to do that. We have a chat or if anyone wants to uh unmute themselves and ask that is also completely fine. Danielle Mark wait here. Were there any particular >> deep deep ciao any particularly deep technical hurdles that you encountered? Uh things that the rest of us might benefit by understanding how you how you dealt with those things? Uh yes, regarding the LLMs actually as I said this um agent support uh using open source LLMs and it's very important that this initially uh when I was de developing the agent I was like trying to think how to do it maybe using like a general prov general um I I I was like trying to make it work with many different providers and my idea was actually to um implement a specific agent, a specific tool which the agent which the LM would be able to call and actually tell um which action do but I understood that probably uh it's better it's in a better implementation using actually native to codes from the models as open source models actually are able to perform better by by doing so and I think that that's very important even for the future with this with this plug-in to continue by having uh uh an implementation with native to tool calls and without creating many abstraction in the agent core logic. >> Thank you. Thanks very much. >> Thank you. >> Uh any closing notes from you, Daniel? Yeah. Um, I want to thank you, thanks the wall jackings community and also a special thanks to my mentors. So, Christian, Shalamba and Shira Gupta and it has been a very fantastic experience and I'm very grateful to you all for this. Thank you guys. >> Y thank you Chris. Uh, yeah, thank you so much uh Daniel for your wonderful presentation. Um, next we have Malikarzun and uh they'll talk about uh how they're going uh continuing building the AI powered chatbot for quick access to Zenkins resources. >> Hey, hello everyone. Uh next slide please. I'm Marik Janji and my project is continue power chatbot for quick access to Jenkins resources and my mentors on this project areas burito and gioani. Here's a quick intro about me. I'm a second year uh B computer science student at Dan Saga College of Engineering Bengaluru India and my interests are mainly in DevOps IML and opensource software. Next slide. Today next slide please. Today I'll be covering the three features delivered this cycle. Then I'll go feature by feature and what is the project scope and also a live demo. And in this cycle um I have implemented the three features the LMS judge evaluation pipeline graph for hybrid retrie and diagnosis agent for build failures. All three of these are now fully delivered and I'll also walk through another feature that has been implemented which came along the way. Next slide please. Yeah. So I had already delivered the LLM as judge pipeline uh by midterm evaluation. So I'll go briefly over the feature and what it does. The problem was that code review alone cannot uh tell us whether the chatbot is actually performing well. A change may look correct in the pull request but still lead to weaker answer or missing Jenkins context or any supported information. So to evaluate this properly each chatbot change is tested against a fixed golden data set containing Jenkins questions and reference answer. We have deep which judges the generated responses using three metrics. faithfulness which checks whether the answer is supported by the retrieved context and answer relevancy checks whether the response actually answers the user question and contextual recall checks whether the retriever brought in enough useful information to produce the expected answer. So this entire process runs automatically in CI. So for every pull request maintainers get clear evaluation scores instead of manually inspecting every response. And if a change lowers the chatbot quality that is also visible directly during CI next slide. Yeah. Next. Graph rack for hybrid retrieval. This was a planned feature post midterm and it has been fully delivered. The core problem is that doing semantic retrieval works by matching meaning and not by tracking actual connection between things. So if I ask does the get plug-in depend on credentials plug-in a vector search can often find a chunk of documentation that talks both about get plug-in and uh credentials together and give a reasonable sounding answer even if that dependency isn't real and on top of that there's a direction problem as well. So if you ask what does g depend on and what depends on g they both are two completely different questions and with two different answers but to obtain semantic search they look almost identical because words and meaning overlap so much. So vector search has no concept of direction of query. So I built a graph directly from Jenkins uh documentation and as well as update center data and every relationship is stored as tight directional edge instead of just a chunk of similar text. That means a graph query can check whether a specific relationship actually exists between two plugins and it can tell the difference between depends on and dependent on by which which a semantic search just can't do. So right now there are about 5,000 edges across uh roughly,400 plug-in and it also refreshes automatically uh as the plug-in data updates and also uh graph isn't replacing the existing retrieval. It's used specifically for dependency and relationship queries while normal documentation questions can still go through semantic retrieval like before. Next slide please. Let me walk you through a sample graph from the talk. And we have here CLV PHP uh and cleavver which are connected by conflict edge showing that they shouldn't be used together. And below that job DSL depends on both STR and script security and below that we have workflow job and docker workflow both depend on workflow step API. So the graph can directly answer what depends on particular plug-in. Then we have three plugins depending on credentials and at the bottom we have a transitive dependency. So workflow CPS depends on workflow API and uh which depends on SCM API. Yeah. Next slide please. Yeah. Third uh the build diagnosis agent. This was still future work at midterm and it's fully delivered now. See the problem here is pretty familiar to anyone who used Jenkins for a while. If a build fails and you are looking at console log that might be hundreds or even thousands of lines long full of build tool output noise and but somewhere in there is actual error uh which explains what went wrong. Finding that manually takes time and it's easy to miss real cause. So the agent handles that automatically. When a build fails, it scans the console log and pulls out the section relevant to the error and discards the rest. And uh one more thing before any of that goes anywhere near an LLM, it passes through a sanitizer. Jenkins logs often contain sensitive values or API keys or credentials that got printed by accident and none of that should ever leave Jenkins environment. So this sanitizer, scans the extracted snippet and masks anything that looks like a secret before it's used as a context. And it's also built directly into the Jenkins UI. So users can just click a button and uh it will be sent to the LLM. Next slide please. So uh you can see a demo of the uh feature three that is diagnosis agent and we have a failed build over here and uh once we navigate to the console logs page yeah so once we navigate to the console log page you can see that the logs are like uh around 200 lines and uh you can also see that there are certain secrets over there and also Jenkins assistant is triggered and then the it shows a prompt like build failure detected would you like to analyze the errors and then you can either click on analyze you can see that there is certain secret keys as well so an O token is present as well as an AWS secret key and a password and API key as well so these values will get sanitized before to be sent to the LLM and also you can see that the error snippets it is at the bottom as well as even in some places in between the logs there are certain uh snippets of errors errors and all of this is extracted and around the logs it is sent to the LLM. So now when you click on analyze it is attached to the text uh area and we also have implemented a model provider selection which I'll talk in the next uh slide but uh you can see that we have GO API open router and other providers as well as local model. For now, I'll be going with block API. And if you click on send, you will uh see that in the uh text that is sent to the LLM uh the O token is being redacted and the AWS secret keys and the password as well is redacted and certain error snippets with line numbers as well is sent to the LM and the response is uh received like in an instant. Next slide please. Yeah. So feature four uh this is third party LLM provider integration and before this the chatbot only ran on a single local model like a 7D model and that had to be downloaded and run locally. That mean setup involved downloading a large model file and running it needed a capable GPU with enough VM which isn't uh something every contributor or every user uh don't have. So now instead of that single local path there's a provider selector. Users can choose a provider and model from a drop-down and uh they can use a hosted providers which works fine without a dedicated GPU. You can see that in the demo UI attached uh there is gro, open router, gemini, cloud and openai all listed in there. So under the hood uh this all works through light lnm which routes each request to whichever provider is selected and adding support for new provider doesn't require much code change as well. So users can enter the provider in a config uh providers.json JSON file and they can provide their API key in the environment file and then they can start using the model and also it is a per user doing their own key setup. Next slide please. So after GSO there are a few things I want to take further. Firstly, packaging the front end with the plug-in uh so that uh installation gets a lot smoother for anyone trying to get started and also running the local back end through docker compose for easier setup and maintenance and so that one command brings the host services up and also extend graph rack to cover conflict or incap incompatibility edges like we saw in between clever PHP and clever uh in addition to the dependency direction and also implement authentication for Jenkins chatbot usage so that every user can access their uh chats even if they start this service later. Next slide. Yeah. So to summarize I have delivered uh LLMS judge pipeline graph ragra and build failure diagnosis agent along with provider integration and also I like like to thank my mentors for being there throughout the project and assisting me. I couldn't have done it without them. Also special mention to Chris for making this whole Jenkins experience special. So if you have any questions for Malikun, please do either raise your hand or you can unmute yourself or ask in the chat section. >> Oh, hi. I see Mark. >> Yeah. >> Yeah. So, where do you see the next steps and do you what what do you see happening as part of those next steps? >> So, plug-in installation should be seamless and like every uh user whoever uh installs the games as well they would uh I would love to have that this chatbot in their interface like being used regularly. Thanks. >> Yeah, sure. >> Perfect. Um, any other questions? All right, looks like we don't have any other questions. If you still have that, you can always use the chat section. So, we move to the next part. Uh so next we are going to talk about the genkins email notification using Outlook SMTP with O. This will be presented by Muhammad. Over to you Mohammed. >> Yes. So hey everyone, I'm Mohammed Raheem and today I'll be walking you through my GSO 2026 project which is uh Jenkins email notifications using Outlook SMTP with oat and my mentors for this project are Alex L and Chris. So a little bit about me. I'm a computer science student studying at VIT Chennai. So yeah, this is my first time contributing to open source through Jenkins and my contact info is up here if anybody would like to follow up after this. That's my GitHub and mail address. So next slide please. So uh about the project. So to recap the problem that we're solving. So email exted authenticating to SMTP servers using plain username and password. And that's a problem because both Google and Microsoft are phasing out basic authentication in favor of Oath. So for uh Google Workspace environments or other enterprise environments, there may not be any other way for uh those users to authenticate. So the goal wasn't just to get oath working with one provider. We wanted to build it in such a way that we could plug in any different oath provider without email exting uh each provider. So next slide. Hello. Yeah. So, oh yeah, a quick rundown on the architecture we started with. So, a little bit about email ext. So, it is a Jenkins plugin that is used for sending customizable build and pipeline notification emails. So, you can uh define your own custom logic for how the email should be sent such as uh the different triggers. for example, if a build is aborted, uh templates that the email should follow and uh recipient list for different situations, that kind of thing. And for handling credentials, it relies on the Jenkins credential plug-in. So everything is stored centrally in the Jenkins credential store rather than email extrets on its own. So moving over to the next slide. So for our implementation in phase one we uh built the uh the oath 2 support on top of the oath credentials API. So the flow was that whenever an email would get triggered, email ext would create a Java mail session object and an authenticator call back and whenever authentication was required, which is usually when we're going to connect with the uh SMTP server, that call back would check during runtime what type of credential is configured and if it's an OS credential, it would uh request the endpoint for an access token and then hand that off to Angus Mail. And Angusmail already has built-in support for XO2. So we didn't have to deal with the encoding or the handshake ourselves. So by the end of phase one, we had a working end to end or SMTP flow. But there was still one uh problem that we had to fix. So next slide. So to summarize that work briefly, uh in our phase one period, we added oath to credential support to email ext. We modify the SMTP authenticator to retrieve tokens and use exoth. We also added retry and error handling around authentication failures as well as failures that happen during uh token retrieval. We also expanded test coverage using green mail so that we could actually catch uh SMTP level o failures. So the problem that uh we had going into phase 2 was related to uh how we were handling scopes which is that when we are fetching tokens we need to pass in a scope requirement object that encompasses the scope strings and that class lives inside the the credential provider plugins. So any plug-in that wanted to fetch a token would have to take a developer dependency on that provider just to construct that object. Which means that for every provider that we wanted to support we would have to add that as a dependency. So that's what phase two is mainly about fixing. So next slide. So for phase two what we achieved so the main focus of phase 2 was to make the uh credential architecture more extensible so that the consuming plug-in wouldn't need to know too much about the internals of uh each provider. So to do that we implemented a capability resolver API for the W credentials plug-in. So instead of the consuming plug-in which would be email ex in our case needing to construct and understand the requirement object by itself the credential provider now exposes and resolves the capabilities it supports as strings. So you can request something like send email as a capability string and the provider is responsible for figuring out what scopes that string actually maps to internally. So email exter needs to worry about the underlying requirement object for every o provider. it can just ask for a capability string and that credential handles resolving it and returning the scope requirement object. So this makes it easy for us to add uh new providers down the line as well. So the next thing we did was we implemented this API for uh the Entra. So for the Entra case which is the Entra O plugin and we also added some basic tests so that we can uh ensure that it works. And another feature that we added was the test email functionality. So before this, if you wanted to check whether your uh email exe configuration was actually working, you would have to configure a whole new job and uh set up a trigger just to find that it was working. So what we did is uh we added a test email button for each account in the system config page. So you can uh select your credential, you can verify that your SMTP port and the credential, the way that they configure and all of that works perfectly without having to uh configure a build each time that you want to do that. So going to the next slide. So yeah, here's a demo. So right now we are in the system config page under email ext. So here we can add a credential. So we have a couple of options here. So we have the standard username and password as well as the o specific ones such as uh Microsoft enter credentials and Google service account from private key. So these are from the provider plugins that implement the o credentials API. So based on what credential we have selected email ext will know which authentication method to use. So here I have two credentials that I've already configured. Jenkeis email test which is the o credential and the other one is a standard username credential. So we're going to use that in order to send a test email. So we can enter over um a recipient address and send a test email just to make sure that our configuration works and everything is right. It should send that. So yeah, we can check our inbox and we can see that we've gotten a test email. So now what we're going to do is we're going to switch over to the oath uh credential which isn't working right now since my trial period with the provider had ended. But we can see here that we're able to see what error occur what error occurred without having to uh configure a job each time. So that's what we wanted to solve with the uh test email feature. And we also have a couple of checks such as making sure that the recipient address that you've entered is actually valid and all of that. So yeah, going uh into the next slide. So a couple of limitations that we had uh with the project was uh number one, we didn't have an Entra application for testing. So we never had access to a real Entra application instance to test against. So we worked around that by using a trial Google Workspace account which let us validate our architecture but it's obviously not a substitute for uh testing with an actual uh entra application. So there is a potential gap between how we've implemented it and what could actually happen in a real uh environment. And the other one is around how errors are handled during token retrieval. So the oath credentials API has a function called get access token which is what we use to retrieve the access token from the credential and the way that API is defined is that it returns null whenever something goes wrong. So the provider plug-in doesn't actually have any information on what went wrong. So on the email exe side, all we can do is when a token fetch fails, we can retry and we have no way to tell whether it's a transient issue or if the credential itself is misconfigured and if it's just going to fail like that every single time. So these are a couple of things that we could look into uh later on. So next slide. So for future work, there's obviously uh we could address some of the limitations and there's also a couple of other things that we could do. one is that we could um extend the uh API that we've defined to the rest of the existing oath credentials plug-in but right now we've only done it for Entra but we could do the same with uh the other providers for example Google which is something that I'm looking into right now and another thing that we could do is add support for new oath providers so we could build new implementations of the uh oath credentials API depending depending on what the community actually asks for so if we do that we'll be able to support a wider range of users and they'll be able to automate their uh email notifications. Uh so yeah, uh next slide. So that would be everything from my side. So yeah, I would like to thank my mentors Alex and Chris. So they were very uh quick to respond and very great to work with and you know, they gave me really good guidance throughout the project. So yeah, I've really enjoyed working on this project for my Got period and it's been a great experience working with Jenkins and I'd be happy to take any questions right now. echo Q&A if anyone has any questions. >> Yes, Mark. Do we have a timeline for when the when those back-end providers of mail services like um Office 365 and Google mail are actually ending support? My worry is how do we comm and then if given that timeline how do we communicate that message to Jenkins users so that they know they've got to make this transition. >> Yeah. So I do think both uh Google and Microsoft have actually already phased out basic authentication. So during the uh initial periods of GSO I had looked into it and this has been an error for quite some time. So I think that's already been phased out and in order to um distribute this information to Jenkins users I'm not too sure on what we could do. Perhaps there are some channels that we could use such as the Jenkins community blog post page where we can uh say that hey we've added this new feature for email extrate to our uh you know to using our uh new o credentials >> thank you >> yeah right any other questions from anyone Okay. Uh so looks good. Uh next we'll move on to the plug-in modernizer uh stats visualization and we have Pratik. >> Okay. Hello everyone. So I work on plug-in modern stats visualization project. This Jop and my mentors will Valentine Chris Sridther and Ra. Next slide. So about myself. So I have graduated from Vune College this year and currently I am a trad. So I am passionate about the open source software and cloud native technologies. My journey started with Jenkins kins in October 2025 during October fest and contributing to plug-in modernizer tool and then I continued it through jaw and I am grateful to be the part of this community. For more info about me you can check it out on my GitHub profile. Next slide please. So this is the agenda to walk through. First I will explain about what is the plug-in modernizer tool then existing metadata storage then about this project then workflow diagram which will summarize the existing scenarios and what we have achieved in phase one phase two then demo and after we will end up the question and answers next slide so a little background first what is the plug-in modernizer tool so it is an CLI tool We apply some recipes to the existing genin plugins. So why we need it or we have a vast genkins community with 2,000 plus plugins and keeping them and updating them manually is a big task. So how we do how does the tool do do this? So there are some specified recipes open rewrite organization and we apply a trans we apply a transformation automatically on a deprecated plug-in and which helps to modernize them. So next slide please existing metadata storage. So currently when the plug-in modernizer tool applies any recipe on any plug-in then it creates a metadata storage and what is this metadata storage? It includes a PR URL did the migration was successful or fail or did the PR got merged and all the transformations are applied to that plug-in. So why it is important? Because it helps to track the modernization process where it was a fail or successful in the recipes. Then identifying the failing recipes which helps to modernize the plugins and also helps the plug-in modernizer maintainers itself on which area it needs to be improved. But what was the limitations with the storage? Currently we store all the metadata into a GitHub repo. So as the plugins are increasing it is very difficult to explore all the plugins and the and the track what the current transformations have been applied by the plug-in modulator tool to each plug-in. So making it smoothly to explore all the work done by the plug-in mod tool. So we think to create a UI site which will display this overall work done by the tool. Next slide. So plug-in moderniz stats visualization it is the current project. So which basically which is an UI site which consumes a metadata created from the plug metadata plug-in modernizer repo and it's fetch that all the data during the build time and presents a dashboard with per plug-in and per recipe reports with an UI form. So the workflow basically are we have created some GitHub actions which aggregate the metadata all the data in the metadata repository and aggregate into our report.json file and it deploys to the GitHub pages and the UI takes that report.json during build time and we display it through a UI through UI uh GitHub pages. So your site contains a dashboard which contains all overall stats. Then a plug-in page which contains the total plugins list and per plug-in details and the recipe which contains all the recipe list and per recipe progress. Next slide. So summarizing through what I have explained till now. So first the plug-in modernizer tool applies open retrite recipe on the genkins community or plugins community. Then when the plug-in mod applies the recipe, it stores the metadata generated during migration into the metadata repository and there are the GitHub actions which gets triggered and all the metadata is aggregated into one single report.json JSON file and then the plug-in modernizer stats UI site is built top on top of it which helps to explore all the data smoothly. So next slide. So what we actually in phase one we made a GitHub actions to consolidated the raw metadata repo into a single report file. Then adding some GitHub actions to deploy that report through the GitHub pages and implementing of a dashboard page which shows the overall stats with the navar and footer and some actions to deploy the UI site on the GitHub pages. Next slide. So in phase two we were successfully implemented the plug-in list page which shows over all the all the plugins which have been app which have been modernized through the plug-in modernizer tool. Currently the count is 431 and it can increase as we go. Also same with the recipe list page which displays the all the recipes. Currently the count of recipes are 21 which were applied to above plugins by the plug-in monitor tool and also the per recipe report which displays the detailed stats about the affected by that recipe and also we have work on the str which adds a snail CLI snippet to a particular plug-in means so it helps maintainers so any maintainer the plug-in mod tool maintainer can copy paste that CL Li command and can apply to a plug-in to modernize it. So we will walk through all this in the next demo slide. So next slide. So I I want to share my screen. Stop. >> Is my screen visible? Yes. >> So currently our project is under the genkins infraite/plugin model and the stats visualization and this is our deployed repo. So first firstly we plan to deploy it on the infra.jenkins.ci pipeline as the genkins.io currently is but later we decided to do it independently deploying to the GitHub pages. So this is the current link for the GitHub pages. So talking about the site, so it is a dashboard page which shows the overall stats about the plug-in modernizer tool. You can check the total plugins affected by the tool. Then the total microes migrations performed by the tool the s and in that how much were successful how much were failed then overall the migration status with the UI site and the cool graphical features then recipe performance then the migration timelines as we go with the time so how plug-in modernizer tool is developing very nice and successful and failure the success count is going greater and failing count is reducing. So which is nice for the two then migration tax the tax which on the these are the tax the the when we create when a plug-in model to apply a recipe then on the basis of what it is doing. So the tax are getting assigned to the PR. So on the basis of that you can see how much we have to turn it and the last the recipe with the most failures. Navigating to the nav bar page when we click on this plug-in then it shows the overall plug-in affected by the plug-in mod tool and there is a filter you can choose to according to the failure rate. So let's talk take the anible plugin. So it tells the current how many PRs has been created by the plug-in modernizer tool to the to modernize the anible plug-in and you can check the recipe breakdown PR histories and the detail migration history how how many CI checks were passed the genkins baseline version target version effective version and you can also view the PR directory we have provided a links number of files will the change and at last the aggregated JSON for all the track of the tool applied to this particular plug-in and you can download it as well and also a CLI snippet if if a maintainer of plug-in moders tool want to apply a recipe want to apply a recipe on any plug-in then you can just copy paste this command and the tool will apply a recipe on that plugin the same way like to the recipe page. So you can see explore the list the all the recipes by the plug-in model to apply and you can filter it through the reds and taking for any recipes then you can see a detail stat that how uh how much mean how many applications were there for with this recipe on the plugins. So there were total 47 and all were the successful and send the CLI snippet to apply any plug-in with this recipe and all the affected plugins the plugins which have been modernized with this recipe. Yeah, that's was about the UI side. Sure. Can you reshare the PPT please? >> Sure. Sure. Let me do that. So talking of the future plans, we are planning to add a page which will display a plug-in health score for any plug-in and which will improve the modernization efforts for a plug-in. And next one we are thinking to integrate AI or using any AI technologies to apply provide a more specific or plug-in level recipes based on the previous modernization data to improve the accuracy of plug-in modern tool and effectiveness of overall the plug modernization process. So next slide. Yeah, that's all. If anyone has any questions, feel free to ask. Yes, Mark. >> So, you mentioned uh the idea for the future of a health score. How does that health score relate to the health score that we currently see on plugins.jenkins.io for each plugin? I assume they're independent of each other or that this is a a health score for plug-in migration, not a health score for the plug-in as a whole or can you enumerate further what you're envisioning there as a health score? Yeah, it can be both. But first plan was to means taking any plug-in and how many how many recipes have been applied for that plug-in. So taking the count into a 100 percentage and how many of that recipes were successful and how many was the fail and according to it it will create the percentage mean it will and independent from my perspective also we can add with the current existing uh plug-in health score but first I thought it was will be the independent on current properly based on the plug-in modernizers stats data. >> Thanks. And I see for instance uh excellent visualization by the way. Very nice. Uh so I picked a plugin off the list and as navigating through there was a failure. Then I looked at the poll request and saw oh the repositories archived. So do you have a a a concept of how you'll handle repositories that are no longer modifiable? So is does that just okay the the data will be static forever or do you remove them? How do you envision archived plugin? >> Currently the data is static and whatever it is present in the metal plugin modernizer repo but in further we can also add any technology to remove the data which is not feasible or which is not any applicable. Valentine can answer this question much better. >> Hey, go ahead, Valentine. >> Yes, sorry, I was mute. Yeah, totally correct. I think uh it's something that we we must do on the the data pipeline is to filter the archive repository. So basically right now we take all uh all data. So all the modernization even for archive plug-in is uh is visible on the dashboard. >> Thanks. Thanks very much. >> Thanks everyone. I was thankful to my mentors Chris Valentine, Ronuk and Sther for guiding me. Also thank special thanks to the infra team for giving us its support and then it was a great experience contributing to Jenkins through Jaw. Thanks. >> Yeah, thank you so much Pratik really appreciate it. Uh next we have Vatzel going to talk about retool genkins website success stories. >> Okay, thank you. So I'm working on reto jetkin sio success stories and my mentors are Chris turn Rajiv Ranjan Singh and Chamo Sahena. Next slide please. So uh this is what we'll be talking about in this presentation. So you'll be knowing about me, you'll be uh knowing about uh genkins success stories project. You'll be knowing what we'll be doing in this project, what uh the project progress and we'll be uh doing some demos for that and uh we'll be taking up the we'll be uh discussing about the challenges that we have and also talking about the future plans and at last we'll be taking some questions. Next slide please. So my name is Vatava. Currently I'm a final year student at ABS Engineering College, Gazabad, India. And I'm a passionate software developer. I am also into graphic design and I like contributing to open source projects and I have started contributing to Genkins back in August 2025 and since then I have been contributing actively and it has been an an amazing journey indeed. Uh you can check out my GitHub profile and LinkedIn profile. Next slide please. Okay. So what is Jenkins IO6 website stories? So gen stories.jenkins.io is an official success story website. So it shows cases how uh different organization have made use of genkins uh in order to improve their CI/CD and uh in order to improve their experience in terms of software development. Also there are currently more than 190 user stories from more than 30 nations all around the globe. So uh purpose yeah purpose is that it showcases how the organization and individuals are using genkins to automate their software development and delivery workflows and it highlights the real world use cases and encourages community and uh wider adoption of genkins ecosystem. Next slide please. So yeah about this project. So this project uh basically aims to retool genkins website success story from uh framework which is Gatsby to wheat in order to ensure faster builds improve developer experience and better performance. So these are the uh lined key objectives. So we need to m we had to migrate the application from Gatsby to V because Gatsby is no longer maintained very nicely. So we had to uh migrate to a modern and a more m and a more maintained uh framework. Also another thing that we need to fix the yl files earlier uh stories.jenkins.io project was a WordPress website. So um because of the migration from that we had to see several inconsistencies because of it there was broken data. So and uh in order to ensure that we are having consistency. So we need to uh have some validations also we need to redesign the entire story submission workflow which is currently broken because of some uh misconfigurations and uh some Gatsby configs. Also we need to modernize the UIUX. Other than that we need to add the code quality tooling in order to ensure application stability. Uh next slide please. Okay. So uh what we have achieved before uh which I mean uh before midterm evaluation. So we have migrated the cont uh entire application from Gatsby to v plus ybased architecture. Also we have uh completed the YAML refinement uh which we were talking about the inconsistencies we have also fixed them and also we have defined a schema validator which is AJV format. So it validates that each and every schema is u each and every YAML file is dedicated to some schema and it is strictly following that and what's ahead it means after midterm evaluation we have redesigned the story summation workflow we have modernized the UIUX we have uh made the interface uh way better than earlier so uh apart from that we have also ensure about the code quality tooling next slide So here we'll be talking about the story submission workflow. So we have taken up two approaches for a story submission workflow. So this is approach one. So um the approach one is divided into three parts. First of all issue template. Uh if a person wants to submit a user story then they will be uh submitting the story with the help of a issue template. That issue template will be having multiple fields in which the data will be fed. on submission it will trigger a GitHub action and GitHub action will uh take uh the uh I mean GitHub action will parse the issue template completely in order to get the data from all the fields and the supporting utils will try to structure the data. For example, uh the issue template will give the data in the form of JSON and the supporting util will try to u validate the data using AJV format and try to structure it in YAML with the help of JSAML dependency and uh uh architection will commit the changes into a directory and it will create a branch and push the commits in it and finally we'll be having a pull request and that pull request will be having the uh index yl file which is containing the story data our story image and code image. Next slide please. So um uh the story uh the approach one was uh shown to infra team. However, it was not very secure and the security was priority. So we had to move to another approach which is decap CMS based which is currently being used on stories.jenkins.io. However, it was misconfigured and there was some error because of Gatsby. So we had to configure it again. So uh decap CMS required uh creating a oath GitHub app and we had to uh uh get a endpoint which is admin and uh the credentials were fed to netlifi so that we can uh see the dams decap CMS UI on uh its endpoint. So uh this is how it works. uh user login via GitHub O to decap CMS UI and uh the decap CMS ask the user to fork the repository. Once the uh repository is forked uh we again have a user story uh form in which the user is supposed to be uh adding the data on submission. It will create a branch and the data will be committed to u that branch and then we'll be having pull request. when the pull request is created, maintainer will check if the pull request uh is good, everything is uh being shown properly on the pre uh preview deploy. So if it is uh if it is okay then it will merge otherwise we'll have to do iterations on the same decap UI uh CMS UI. Once the changes are done, it will automatically commit the changes on the same PR and we can have a deploy again. Next slide please. So, uh let me share my screen. Okay. So, I hope my screen is visible. So, currently we don't have our project merged on main. We are having a GS 26 VM branch. So, that's why I had to deploy it uh by myself and we don't have a PV deploy. Yeah, this is how our website looks like. So this is our new Jenkins IO website success stories uh with with a new modern UI. So the we are having two CTAs share your story and read all stories. We'll talk about the later then if you go down we can uh uh I think let me yeah uh so we can have three actions which is user story, explore map and case studies. Yeah, we have case studies. Previous website did not have case studies. So, I had to uh go to internet archive and uh fetch up all the information about it. So, uh let me open it. We'll we'll have a look on that. Uh other than that, we have uh five stories on the landing page which are latest stories by different organizations and other than that we are having another action which will m uh which will take us to our map functionality. So, So this is how our case studies looks like look like. So we are currently having six case studies from different organizations. So let us look how they look like. So this is one of the case studies. We have uh we have our heading by whom it is written. We have image and we have body content. So this is how uh stories look like case studies. So and uh let's go to the user story uh I mean the map functionality. So this is how our map functionality looks like. It shows different user stories from all around the world. And uh if you click on any of the user story then we can redirect to that uh user story. So this is how individual user story looks like. We have our breadcrumb, we have our heading, subheading, we have our metadata and body content along with testimonial at the last. Uh yeah and we also have a navigation so that we can uh look on other user stories as well and this is how our other user stories looks like. So if you want to have a collected collection of all the user stories you can check that out on the all route. So here are user stories which are sorted by u decreasing order of the date mentioned. You can also check out the user stories from here as well. And if you want to uh search any user story, you can uh definitely search that. So yeah, this is how our uh website looks like. So let us see how we can submit a user story. For that we need to go to admin. We can also use the share your story button. For that uh we need to make sure that uh user who is not having right access can submit a user story. So that is why I will open the website in my other account of GitHub which has no relation to our uh Jenkins organization in order to make sure that an external user can submit a user story. So this is the decafs UI. It uh asked for uh forking the repository. However, it did not ask me because I have already configured it. So, if you want to share a user story, you can click on the user uh new user story button. Then after that, you can start filling it like uh let me fill it real quick. We have some required fields. So, we need to fulfill the things from here. We can upload an image. Let's take this Jenkins logo. Then we have our metadata. Let's keep it as testing organization. We can have Jenkins. Uh we can also have company website. Same goes for project website. There is a possibility that it may differ. We have different uh fields for metadata like industries. We can fulfill it as per our need but they are optional. If you want to fill them you may. Then we are having a testimonial by whom it is written the content like you want to share a testimonial Jenkins is the best like we can do it right there. Okay. Uh so and uh other than that we need a code image. So we have selected a code image. So we also need the geographical uh things for this uh location should be pointed to where you live and you can also select your the location from this open street gojson map. So I have selected it and also you can see that on the side panel. Yeah the all the information is uh there. However the images appear to be too big. Uh also we need to add the body content for this. Let's add some paragraph. For paragraph we'll take Lauram 100 for now. Okay. Let's take Lauram. Okay. I think so this should work. So once we have uh filled all the fields we'll just click on save. So we can see that our entry has been saved. So if we go to the repository we can see that there is some commit on the repository. If we try to pull and compare it we can see that we are having three files. One it is having a YAML file consisting of uh all the metadata and the YAML other fields. Also we are having a genkins logo and we are having a code PNG which is required. So uh if you want to create a pull request for this uh either you can do it from here by clicking on compare and pull or you can do it from here. You just need to update the uh status from draft to in review. Once we have clicked on it, you can see that uh a pull request has been created for the commits which is this. So it will take some time to deploy on netlifi. Till that we can also uh again have a look on our uh generations. So yeah we have everything in structured in a proper manner. However, uh we also needed to make sure that it is working on a strict uh schema. So, it is also validated by AGB formats. So, it will be done by the CI. So, let us see. I think so uh deploy must have been done. Yes. So, if we go on deploy, so our slug name was post one. So, let us navigate. Okay. We don't need to navigate. So, we can see our latest user story. So here is our user story that we have just submitted. It is it feels empty because we have not submitted much in that. So this is how uh it looks like. We have our breadcrumb. We have our um title, subtitle, authored by, we have our metad description, body content, testimonial and our testimonial image at the last. Also if you uh want to um do changes in any of the uh any of the pull request I mean on any of the story you can directly go to the u actions which are given on uh footer which will directly take you to the source path uh like this. However, this is currently pointing to the main repository. So it will not show anything. So yeah this is how a story submission is working and any person from other than organization I mean who is not having a right access can uh share a user story. So let me stop sharing. Yeah you can share. Hello, here. >> Yeah, give me one second. I'm just figuring out the One. I'm just setting the >> No problem. Okay, should be good to go. Okay, thank you. So, uh yeah, so here are our challenges. Yeah, configuring storage submission workflow was actually the greatest challenge I I saw in this project. So we had to ensure that it is working for each and every edge case since the metadata and the YAML files are not consistent in all the stories. So we had to define a strict uh schema and had to make it perfect for each and every edge case. Also uh redesigning the UI was another part because we had to create a lot of iterations. However, we have also redesigned the contributor spotlight project, but we are uh low on time. So, we cannot show that. Next slide, please. So, here is our future work. So, we need to make the story submission guidelines more detailed because it can be confusing a little bit that uh there may be some errors while submitting a user story. So we need to make it more detailed also uh single page applications show a little problem uh of 200 okay status that uh even on the non-existing route or the pages that don't exist they throw a 200 okay status uh instead of 404. So we need to uh fix that as well. It is it will require the redirect rules. So we need to uh impose them and there are some future possible additions that uh for each and every uh user story we can have a summary generated maybe with the help of AI uh because they uh content in each user story is too much and also maybe we can have a audio playback for user stories which is working on uh browser internal functions which is speech web API I think. Um yeah next slide please. Yeah. So if there are any questions you can ask me, >> go ahead. Mark, >> you mentioned data compatibility challenges. Any automation that helped you detect data compatibility changes? How do how did you handle that? Because of course the thing like you said it came from a WordPress site that was maintained by human beings and and thus it was we were really grateful when it was translated automatically into a data format that was wonderful but the human beings who started it off were certainly imperfect and flawed in what they did. How did you handle the the data transformation the data correction and without losing data? >> Yeah. So uh definitely it was actually a headache for me. So uh before GSOC I made around 24 PRs uh 24 to 25 PR to uh fix the inconsistencies in data and after getting into GSOC we tried to impose uh agave format. So what ag format does if it finds any yl file which is not uh following the u data I mean which is not following the strict schema so it will flag us it will just give the file name to uh us in console. So uh it helped us a lot in order to identify which files are imperfect and uh yes we u use ag formats in order to do that. Yes. >> I hope you uh >> Thanks. Yeah, that that's Thank you for doing the work. It just feels like it's an enormous amount of work to do data cleanup like that. Thank you. >> Yeah, indeed it was. Thank you. >> Uh thanks a lot. Uh any other questions from anyone else? Yeah, but I I I would like to say something. I would really like to uh thank my mentors Rajiv Singh, Kristen and Jamu Sena for uh guiding me throughout this program and it was really an amazing journey and there was some ups and downs. We had to change our way of thinking sometime we have to change our implementation and it was interesting. Yeah, definitely. And thank you to Jenkins community for uh such a wonderful experience. Thank you. >> Yeah, thanks a lot. And of course, you know, like to also give a shout out uh and special mention to all of the mentors because um you know, of course, the star of the show is typically the mentees because you know they are um doing a lot of the work around uh building the actual projects themselves. But of course mentors are also giving their time and uh kind of helping out the mentees whenever they are stuck. So we'd like to really like to thank all of the mentors for their dedication uh to the projects. So for the AI chatbot we had Chris uh myself and Jarag. Then uh we have um for the AI powered chatbot we had V, we had uh uh Binato and Gioani. Uh for our SMTP project we had Alex, Chris. Uh plug-in modernizer we had Valentine, Chris, Shridhar, uh and Ronak. And for the success stories, we had Rajie and Shammud and Chris as well. So of course you'll find Chris was like not only helping with u being like the you know one of the org leads u but also like helping with so many of the other mentors. So special shout out to Chris for really spending a lot of the time and helping in so many different projects. Um and uh of course to all of the other mentors um since we have like a little bit of time if any mentor would probably want to share um their experience. So like one of the great things about being in a you know community like Jenkins is that you you'll actually see that a lot of the mentors uh who are this year they were actually mentees last year. So Churag was a mentee last year and I was a mentor for Chur's project with and Chris and now you know he was also one of the mentors. So like that's one of the great things about the community at Jenkins because it's a very closely knit community. So if you are active uh we always invite you to be a mentor if you have been a mentee in the past. So you know if any mentor would like to probably like share their experience maybe a minute or two uh I'll open up the floor if anyone wants to volunteer. Yeah, I can talk about my experience like I did also the mentee last year and I've done the mentor this year and honestly it's been great also to firstly like have the possibility in my case to continue the same project that I developed last year. So this was the case but also to try like improve in general what is in my case was like the plugin whatever it is like in the in the ecosystem. So I think that's great. So I suggest it also to any current mentee that would like to help in the future like for as a me. >> Yes, Mark. >> I like Giovanni's observation that that the work is usually not all the way done when we reach the end of Google Summer of Code, right? Things continue and so it's it's an invitation to keep going. I am I am curious Giovanni if you had insights on things that helped you stay motivated and interested or things that hindered. >> Yeah, like the thing was that I did the project last year because I was like really interested in the field. So like it was another continuation like in doing kind of the same thing that I wanted to do last year but obviously in 3 months or like two months and a half you don't have like the time to finish everything everything up and also now I think there are like a lot of steps that separate us like for the plugin that we developed from having something that is actually like could be really usable by a user. I think we are really far from that but uh probably with another one two years we can improve a lot by the contribution throughout the year and obviously the work during Jesus. So I think that's the thing. >> Thank you. I really appreciate uh feedback from uh and Mark. Um anyone else? So we are just around the time. Uh if any other mentors would like to share maybe their experience in a sentence or two otherwise again like uh a huge thanks to all the mentors for you know their time and of course like guiding the uh mentees. Uh maybe like Chris I I would like for you to share maybe like a minute or two because I know that you were involved with so many different projects and also being an or admin I'm I'm putting you on the spot but if you want to share maybe like in a minute your experience. >> Um just want to share like um even though it takes a lot of effort to make it happen like seeing like all that succeeding this year's means a great deal to me. It's like I just want to appreciate like just want to thank everyone also thank everyone new coming here to like join our chat or presentations today. >> Perfect. Thank you so much Chris. Uh yeah with that we will conclude our session. So we are left with about 3 minutes before we end uh before the time. So in case anyone else wants to share some any last thoughts uh maybe in the chat or on uh you know on the call uh but again thank you so much to all the contributors for uh sharing about your projects and for everyone who uh asked great questions. So special thanks to Mark as well um and all of the attendees who were there throughout today's session. Of course, as we mentioned that this was recorded and we'll be sharing uh this uh know once it's live, we'll share the YouTube link on the guitar and the discourse. But if anyone else uh is interested, of course, all of the details about each and every project is already available online on the uh genkins website as well. If you want to try to uh run these projects or maybe like reach out to the mentees or the mentors, you feel free to do that. Um and this was our effort to like showcase and highlight the great work that each and every mentee did throughout this Google code 2026 and uh hopefully if you know things go well we'll be there for the 11th year in 2027 and in in the meantime you have a great opportunity to look at the other projects in the ecosystem. A lot of them uh you know find sometimes like menty uh the maintainers of the projects they have to leave for uh you know XY Z reasons. So you can always reach out to us if you're interested in becoming a maintainer for one of the plugins. Uh you use a plug-in and you want to become a maintainer. Do reach out to us. There are ample amount of opportunities to contribute uh in a wide spectrum of different projects ranging from AI to core genkins uh core Java DevOps um Groovy. So whatever language that you're interested in, you'll find something or the other which is relevant for you. So again a huge thanks to everyone who came and uh we conclude today's session. >> Thanks everyone. >> Thank you. Bye-bye. >> Thanks very much. >> Thank you everyone. >> Bye-bye. >> Thank you. What?