2026-07-02 GSoC 2026 Midterm Presentations

Okay. All right. Good morning, good afternoon, and good evening everyone. Thank you for joining the Jenkins online meetup. Today's session is Jenkins in Google Summer of Code Midterm project status and demos. My name is Shinwas and I'm one of the organ organization admin for Jenkins this year along with Chris Shivai. I'll be walking you through the full introduction today and then I'll hand the things over to our GSO contributors who are really the main event and our mentors are also on this call and will help out with the questions as we go on and yeah quick word on the Jenkins online meetup itself. It's a communitydriven virtual platform. The goal is to inform, transfer knowledge and share all things Jenkins case study, success stories, whatever useful to the community and we are always looking for speakers. So if you have got a story worth telling, reach out through the link visible on this slide and a few housekeeping notes before we dive in. This session is being recorded and we'll share the link afterwards. If you have any questions, drop them in the Zoom chat as we go on and we'll try to answer them live at the end of each project. And if we run out of the time there, we'll hold a broad Q&A at the end if you have ample amount of time. You can also find us on the Jenkins Gox Matrix channel or on the community discourse after the event as well. And of course, yeah, our code of contact conduct applies throughout. Treat each other with respect and kindness. And so here's what we have got for the today. A short introduction to GOC and Jenkins involvement in it. Then project demos from our GOC contributors and 12 minutes each including questions and we'll close the close with our open Q&A as well. And this is for anyone new here. Google Summer of Code is one of Google's flagship program. It matches opensource organizations and their project ideas with mentors and contributors. Organizations propose project ideas and community members volunteer as mentors as you know and then contributors apply with their own plans for tackling our project over all the summer and after evaluation one contributor is selected per project and Google confirm the final slot count for each organization and this year makes Jenkins 10th year participating in Google summer of code which says a lot about how consistently strong this program has been for us. We had five project slots this year same as the last year. That's a record. I mean it tells you a GOC sees Jenkins as a genuinely good organization to work with because our mentors put in the effort and our contributors deliver real last work. A lot of power g projects are still actively used it today as well and you can find the full list of this year's ideas and link to previous year project on the g page at jenkis.io as well and finally let me introduce this year five contributors Daniel Muhammad Pratik Malikun and Versalwama. You'll be hearing directly from each of them shortly, so I won't steal their tender. Just know that each of them has been heads down all summer on some genuinely useful additions to these Jenkins. And of course, none of these happens without our mentors. So a quick shout out to our organization admins Chris Shay and myself as well and our mentors who's been putting in the weekly things the code reviews the late night slack answers are Alex Valentine Rajiv Banto Chammud Chiag Gawani Shrther and finally Ranak thank you all this program simply doesn't run without you And with that, let's get into the project presentation from our GSO contributors. If you want to follow along or dig into the details afterwards, all these project pages are linked in the U provided the link visible in the slide. And our first project today is EI chart to guide user workflow presented by Daniel. And Daniel over to you. And whenever you want to change the slide, let me know. I'll change the slide. >> Okay. >> And Daniel, over to you. >> Hi everyone. I'm Daniel and um you can go next in new slide. And um I'm a Italian computer science student at the University of Camarino. I'm a passionate developer and I from this year I started contributing to Jenkins and I'm very happy to be part of this great family. Um you can go next. My project is about creating a plugin and as every plug-in in in Jenkins each uh each plug-in solves a problem and for for this case this my my plug-in has aim to help the users to troubleshoot builds and faulty pipelines and also help beginners in discovering and configuring jackins. So uh I decided to create a a plug-in which integrates an a agent and uh specifically a chatbot which uh so the user can interact with this with this chatbot and the user will be assisted in maybe solving problems. So maybe troubleshoot a failed bid or also maybe there's a problem in the pipeline and also if the user is a starter the chatbot will be uh very helpful also for for them and you can go next. We can see here the architecture of the plug-in. Actually, we have a front end which is actually a sidebar, a set panel. So, where the user can interact with the chatbot and it is built in a React plus framework and our our front end interacts with a Jag controller which is which acts as a proxy between the front end and our back end where our core logic lives. And in the back end there will be host the agent and the back end will also be connect to the to a posgql which is a database where we'll be stored the chat history and there will be also a quadrant database which is a vector database and it's very helpful because uh it give us a native aid retriever which will be helpful for retrieving our actual vectors. So the data that will that the chatbot will use for to in order to answer to the user and also there will be the chance to use a specific local model with so open source models or open weight or maybe if the user prefer will be also possible to use third party LMS you can go next. So starting with the Jenkins data which will be stored in the kand database we will have four different different types of source of data. The first one is the Jenkins documentation. The after the plugins documentation which is actually the documentation of each specific plug-in existing in Jenkins. Al also we will have the discourse topics which are all the most useful uh topics actually stored in in Jenkins discourse and also we'll uh get the most famous uh Jenkins uh Reddit threads and uh after collecting this data the data will uh go in a pip pipeline which will be preprocessed. So we will uh keep only the most useful data. For example, for this the discourse topics, we will get just the uh topics which have actually a concrete solution. So which are really useful for uh users and the data will be format and also chunked and at the end embedded and stored in the vector B. Um you can go next. So we say that our plug-in is actually actually as an agent which helps the user and there will be an agent loop. So where we will have our router LLM which uh read the question that user has made and we'll decide if there's enough information to answer it. If there are not, it will be able to use some specific tools to get together more information. For example, uh one of these specific tools will be the ad driver which will search in the qu could vector DB and we get the most related data to user question. We have also other information for example getting the contest the Jenkins context information which are the data for of the specific Jenkins instance that the user is running. For example, if the user is currently watching a field build, uh when the user make a question, he can attach the context and the chatbot will read the context and also use that in order to give a useful uh response. You can go next. The chat is opened by clicking a button at the bottom right and uh you can go next. So it show the actual chat UI and there will be a a common chatbot UI where the user will be able to make specific question and in in at the bottom right we have the attach button context. Um so the user uh by clicking that will attach the context and the it will be stored in the back end after being vectorized. Obviously you can go next. Yeah, this is the actual button. Uh you can go next. Regarding the testing and clean and clean code, uh I'm using a specific link and formatters for for example black for formatting the Python uh back end code. And I'm implementing unit and integration test for both the uh plug-in itself and the back end. in Python and for testing the land graph and agentic logic I'm using I will use ragas framework which will evaluate the faithfulness context recall and answer relevance of each uh specific um loop of the agent. So after uh specific output of uh uh of the agent and we it will obviously use a a golden data set which will be used to test this specific agent. Um you can go next. Uh for now I'm I've already implemented the context. I've already implemented the data retrieval logic and also the front end UI as as you have seen and I'm I will work in the next weeks to the context data retrieval and the the agent core logic the specific tools which will be given to the agent and at the end the testing so using the regas evaluation framework uh you can go next okay so if uh anyone has a question I'm happy to hear. And before I want to thank my mentors which are Chris Stern, Shiva Lamba and Shira Gupta and they have been really helpful this weeks these past weeks and I want to thanks them for being so. So if you have any question I'm happy to hear. >> That's awesome. Daniel, you are on the time as well. So, so everyone we have 1 minute for if you have any questions feel free to add it in the chat as well and feel free to unmute yourself and ask the questions if you have any. Okay, so we can move to the next one. So the next up on the line is continue powered chatbot for quick access to jenin resources. So Malika Jun over to you. Yeah thank you. So hello everyone I am Malika Janjiri and my project is continue AI powered chatbot for quick access to Jenkins resources and my mentors are Bhuturi Burvanto and Gioani. So this project continues the previous work on the Jenkins chatbot. The main goal is to make the chatbot stronger, easier to maintain and evaluate. In this presentation, I'll cover what I have delivered so far, what I'm currently working on and what I'll be doing next. So before proceeding further, sorry, previous slide. Here's a little about me. I'm Malik Janji. I'm a B computer science student at Danasal College Engineering Bangalore. I am interested in DevOps, a IML and opensource software. Next slide please. Yeah. So coming to the delivered work, the main deliverable so far is LLM as a judge CI pipeline. The problem is that chatbot quality cannot be judged only by reading code. A pull request may look correct during review, but the chatbot's actual answer can still become worse. It may miss useful Jenkins context, give a weaker answer, or hallucinate unsupported information. The solution is to evaluate chatbot changes using the fixed golden data set generated output and deep judge metrics inside CI. So instead of only depending on manual testing, the pipelines gives maintainers a repeatable way to check chatbot quality during pull request review. The outcome is a PR level result. This gives maintainers a quality signal that helps them understand whether a change is safe, useful or needs more review. Now coming to how the pipeline works. The flow starts with the retrieval artifact cache check. So if the cache is already present, the pipeline skips the build step and directly continues to response generation. If the cache is not present, it builds the retrieval artifacts first. After that, the chatbot generates responses using the golden data set. Then deep acts as the judge and evaluates those generated responses using this elected metrics. Finally, the pipeline produces PR result. Next slide, please. Yeah. So, let's take a look at how the golden data set used for the evaluation pipeline looks like. As you can see, we have four main fields. Input out expected output, retrieval context, and metadata. So, the input is a Jenkins related user question. As in this case, how do I configure the Git plug-in with credentials? This is the question passed to the LLM during response generation. The expected output field is the reference answer used for judging. This field represents what a good answer should contain. The retrieval context field. The retrieval context field contains the supporting chunks used for evaluation. These chunks provide the evidence needed to support the answer. Finally, additional metadata stores tracking information like question ID and source documentations. This helps identify and debug specific evaluation items later. Next slide please. Yeah. So now coming to the evaluation metrics. The three main metrics are faithfulness, answer relevancy and contextual recall. So faithfulness checks whether the generated answer is supported by the context. It is important because even if an answer sounds correct, it should not make claims that are not grounded in Jenkins context. This metric helps catch hallucination and unsupported claims. Answer relevancy checks whether the output actually answers the user's question. An answer may be technically correct, but if it does not answer what the user asked, it is still not useful. In other words, it keeps the chatbot focused on answering what was actually asked. Contextual recall. It checks whether the retrieved context contains the information needed to produce the expected or answer. If contextual recall is low, it usually means that the retriever did not bring enough useful evidence. This is where retrieval side of the chatbot gets evaluated. Together, these metrics help identify where the failure is. Sometimes retrieval context is weak, other times the context is good but the model still gives weak or unsupported answer. Now coming to the metrics on the right side, the current benchmark threshold is 0.85. This means 0.85 is the minimum benchmark we expect the metrics to hit and it is not a forced improvement target for every run. The current scores are above this benchmark with contextual recall around 0.92 and faithfulness and answer relevancy around.88. Overall the delivered work gives a structured and measurable way to uh review chatboard quality. Next slide please. So now coming to what I'm currently working on at this stage I'm working on graph rack for hybrid retrieval. The current retrieval system works well for normal documentation question when where the answers can be found from relevant text chunks. But some questions are uh relationship based. For example, a user may ask uh what plug-in depends on this plug-in. So at that time uh for those question normal vector retrieval may not be enough because the answer depends on how the entities are connected. That is where graph helps. The important point is that graph is not replacing the existing retrieval system. It is just being added as an additional retrieval path. Normal documentation questions can continue using the existing retrieval flow and relationship heavy question can use a graph based evidence along with normal retrieval context. The diagram shows the architecture from left to right. On the on the left, the flow starts with input files. These include plug-in names and plug-in documentation chunks. From these inputs, the graph layer extracts relationship. A simple way to understand this relationship is entity relationship entity. For example, plug-in A depends on plug-in B. These extracted relationship become triples and the triples are used to build the plug-in graph. The next part shows that the generated graph files. These include plug-in graph, extracted triples, rejected triples. We need to know what relationships were accepted, what was rejected, and whether the graph is reliable enough to use during retrieval. Then the integration section connects the graph into the existing chatbot flow. When the graph context is useful, it can be appended to the normal retrieval context. This way, the chatbot can answer using both normal text evidence and graph-based relationship evidence. Finally, testing and evaluation section checks whether graph rag improves relationship based question without hurting normal documentation style question. Next slide, please. Now coming to our upcoming work, I'll be completing the implementation of two features. Graphra as I discussed in the earlier slide and the second feature the log analysis diagnosis agent. I have divided graph into phases with each phase incrementally building toward completion and then the first phase is the graph build phase. The this gives the pro sorry this gives the project the base layer needed for graph based retrieval. The second phase is graph retrieval. This involves detecting important entities in user query, finding related graph connection and ranking these result. The third phase is integration and evaluation. The graph retrieval will be connected into the existing chatbot flow with fallback behavior. After completing graph flag rack, I will be moving to feature number three which is diagnosis agent. This feature focuses on Jenkins pipeline failure analysis. The diagnosis agent will help identify the key failure section and explain what likely went wrong. As we all know, Jenkins locks can become very large and users may not immediately know which part actually caused the failure. The diagnosis agent works as follows. It finds the error section, strips it and passes it to the sanitizer. The log sanitizer scans the logs for environment values or secrets and masks them before sending them as a prompt to the LLM. The second part is making the feature accessible from the Jenkins UI through a plan jelly button. Upon pipeline failures, users can click this button and the logs are stripped, masked, and sent as a prompt to LLM. This makes failure analysis safer and easier for a Jenkins user to access. Next slide, please. To summarize, the main deliver work is LLMs as JCI pipeline. I'm currently working on Graphrack and will be implementing diagnosis agent. I would also like to thank my mentors for their guidance, support, and feedback throughout this project. That concludes my presentation. I'm happy to take questions. >> Yeah. Yeah. That's some Malik Arjun. So, we have a one minute for the Q&A for Malik Arjun. So, guys, if you have any questions, please feel free to ask. Okay. If there are any questions, you can feel free to add it in the chat. We can pick up those questions later as well. And being said that, next we'll be going through Jenkins email notifications using Outlook SMTP with OAT and Muhammad Fahim. Over to you. >> Yep. Thank you. So, hey everyone. I'm Mohammed Fahim and I'll be walking you through my G-Soft 2026 project which is Jenkins email notifications using Outlook SMTP with OT and my mentors for this project are Alex and Kristen. So next slide please. So here's how I structure this. I'll talk a little bit about me, the motivation behind the project, our main project goals, uh some background on how Inex works, our implementation, a demo, our testing strategy and then the challenges in future work. So next slide please. So a little bit about me. I'm a computer science student at VIT Chennai based in India and this is my first time contributing to open source at this game. So I really enjoyed getting to work with the Jenkins community and my contact info is up here if anybody would like to follow up after this. So next slide please. So uh about the project. So what is the actual problem that we're solving? So, email exe currently only supports authenticating to SMTP servers using plain username and password. And that's a problem because both Google and Microsoft are actively phasing out basic authentication in favor of oath. So, while personal accounts may still support basic o for Google Workspace or other enterprise environments, there may not be any other way. So, next slide please. So for our project goals, we set four main goals for our first coding pace, which is going to be to get a working oath uh SMTP authentication flow in place. Uh make it easy to plug in multiple different oath providers. So not just for outlook. Uh keep solid test coverage on anything new that we add and make sure that the configuration experience for the end users uh stays simple. So next slide please. So uh before our implementation, here's a quick rundown of how the email exe plugin actually works. So it is a Jenkins plugin that is used to send customizable email notifications for your jobs. So it gives users a lot more fine grain control over their email logic. For example, you can configure different triggers for when your email should be sent such as if a build gets fixed, aborted, uh etc. It also supports uh custom jelly and groovy templates that can access the gem uh Jenkins API so that we can include build information directly in our emails. And uh the key point is that email exe doesn't manage credentials on its own. It does that with the help of the Jenkins credential plug-in which is a pretty standard way Jenkins handles secrets such as passwords and tokens. And this is great because credentials are stored centrally using the Jenkins credential store and it's what we built on top of using the oath credential interface. So the diagram below shows the existing flow. Whenever a build finishes, email extriggers have fired and if so, it resolves the recipients for that trigger. It builds the email and then it creates a mail session object which contains all the SMTP properties such as timeout as well as the authenticator which decides how authentication should take place. After which we execute the present script, connect to the SMTP server, send the mail and run our postcript. So next slide. Moving on to our implementation. The core idea was to separate the two responsibilities which is retrieving an oath token and using that token to authenticate over SMTP. So token retrieval was delegated to the credential plugins which implement the oath credential API. So email ex's only job is to consume whatever the provider would return. So from the users perspective in the bottom left they would configure an oath credential for their Google workspace or Entra account in the Jenkins credential store and then they would selected for email exe in the system config page and on the plug-in side whenever an email would need to be sent it would Java mail would create uh email exe would create a Java mail session and register an authenticator call back and whenever authentication is required Java mail would invoke that call back where we have our logic for authentication and how that works is we inspect the runtime type of the configured credential and branch from there. So if it's a standard username password credential, we simply convert the secret store back to a string. And if it's a standard username or two credential, we call the underlying implementation of get access token in order to retrieve it. So once we have a token, our authenticator hands it back to Java mail which already has XO2 support. So we don't need to worry about how the tokens encoded or performing the handshake. We just have to set the right session properties which is XO2 in our case. So all the provider specific oath logic lives outside MXT inside the individual credential plugins for the token such as managing caching handling token refresh all of that. So they're all self-contained as their own independent plugins. So if another plug-in wanted to use oath they can do so. So at the moment we still have to explicitly handle each provider such as Google and Microsoft on the email exe due to limitations in the current uh current O credentials API which I'll come back to when I discuss the challenges. So next slide. So uh here's some screenshots to walk through the flow. So we are in the system config page for Jenkins and under email exe we're going to be setting up a mail account user. So how we would do this is we would click on the add credentials button from where we can see the different credentials such as Google service account and Microsoft enter ID credentials. So these are the credential types from the provider. So we can select for example Google service account and in that we can fill in our required details and create it and once we're done with that we will select it under the config page and moving to the next slide. So for a particular job we would configure a new post build action for it and here we wouldn't need to do any extra configuration for oath. So the user can just set up their email logic their triggers and scripts and when the build gets triggered uh o the email exe plugin will know which o mechanism to use from the credential selected itself and send a successful email. So uh next slide please. So uh for testing, email exe has been around for quite some time. So it has a good testing foundation using JUnit 5, the test harness and mojito. Uh so Mojito was really useful for us because some of the dependencies that we're interacting with are Jenkins extension points. So rather than creating our own test implementations or trying to config them using the Jenkins test, we could just mock them directly and control exactly how they responded, which made it easy to verify things such as our retry logic. We also added green mail as a dependency since email extra mail before that which couldn't catch SMTP level failures since it intercepted any SMTP communication. So we were able to use this to verify that things such as authentication failures and incorrect credentials would actually surface the right errors in the bill log and not get silently swallowed. So uh next slide please. So thank you. So uh on to challenges and future work. So as I had mentioned, one of the main challenges we ran into was around how the oath credential plug-in exposes access tokens. So to retrieve a token, we have to pass in an oath to scope requirement object. Uh so this tells the credential which scopes the request and is also used for filtering credentials. The problem is that this class lives within the credential plug-in itself, which means that any plug-in that wants to fetch an oath token has to take a dependency to construct that requirement object. So there are some potential fixes for this. For example, we could define an interface in the API that could let the credential itself return the requirement object such as maybe a factory of some kind to create the requirement object from strings. However, this would require changes to the oath credentials plug-in which isn't maintained by my mentors. So getting changes reviewed is difficult, but it is definitely something that we'll be addressing in the future. So uh looking ahead, our main focus is going to be on getting our changes polished as well as providing documentation. So we'll be writing thorough documentation for how to set up credentials, how to configure email exe to use them, as well as a troubleshooting guide for common setup issues. We'd also like to add a send test email feature so that users will be able to validate their entire configuration with a single click instead of having to set up a test job or a build and debugging using that. So next slide, please. So that's going to be everything from my side. Uh before I close, I would like to thank my mentors, Alex and Chris Darn. They were always very quick to respond and were very nice to work with and gave me great guidance throughout the project. And yeah, I'll be happy to take any questions now. Thank you. >> Yeah, that's super awesome Muhammad and all the best for your future workflow. And we have two more minutes for the questions for Muhammad. If anyone have any questions feel free to ask for the Mahhamad we have a two more minutes for the questions. Okay, nevertheless if you have any questions feel free to add it in the chat. And moving to the next we have plug-in modernizer stats visualization by Pratik Man and Pratik Man over to you. >> Yeah, thank you. Next slide. >> Okay. Hi everyone. So myself Pratik Man, I am contributing to plug-in moderniz stats visualization project and my mentors are Valentine, Chris, Sridar and Ron. Next slide. So bit about myself. I am a final year BCK student in VIT program and currently internet rad. I am passionate about the opensource software and cloud native technologies. My journey started with the plug-in modernizer tool in October 2025 during the hectober phase and grateful to be the part of the community and if you want to explore more about my opensource contribution then you can check it out on my data next slide. So this is agenda. First I will go you through the plug-in modernizer tool. Then the existing scenario for the metadata storage. Then about my project, why we need it. Then the progress till now. Then short a short demo. Then about the future plans and Q value. Next slide. So about the plug-in modernizer tool. So plug-in modernizer tool is an a tool which applies a open open rewrite recipes to modernize the plugins. So there are over 2,000 plus plugins in the genkins and keeping and updating it manually is a very big task. So plug-in modernizer tool automate it. Next slide. Next slide. Okay. So the existing scenario. So there was a metadata storage repo which stores the metadata created during the when the plug-in modernized to tool applies a recipe on a plug-in which includes the PRs the migration successes or not the PR is merge or not. So it's important because it helps to track the data and the work done till now by the plug-in modernizer too. So next slide. So going through the repo was very hectic task because it has many uh directories and folders. So a new idea come up which is an plug-in model stats visualization which is basically a static visualization site which consume the metadata during its build time and presents the dashboard and per plug-in reports and per GCP reports. So workflow is basically the whole metadata repository is aggregated into a single report which is a JSON file through the GitHub actions and which is deployed through a GitHub pages and then this report is fetched during the build time and a static UI side is deployed on it on the top of it and the UI site includes the three parts. the dashboard which shows the overall stats of the plug-in modernizer. Second is the plug-in page which shows all the plug-in list and per plug-in details and same as the recipe page total recipes and per recipe progress. Next slide. So the progress till now. So I have created a GitHub actions which consolidated a raw metadata into a single report and a GitHub action deploys the report in via a GitHub pages and a dashboard containing all the stats and the navbar on the top of it and there is a separate GitHub actions to deploy the UI side which can be seen which can be seen on the plug-in model and the stat. So till now I have done the initial base and adding some test case for the dashboard page and the currently the plug-in list and per plug-in reports status is in progress and next plan would be the recipe page. Next slide. >> So for the demo >> should I share my screen? >> Yeah. Okay. I'll be stop sharing my screen and then you can start sharing yours. Let me stop sharing mine. Okay, I guess you can share it now. Okay. >> So, are you able to see the screen? >> Yes, we can. Oh, so this is an metadata plug-in modernizer repo which is the track of the overall work done till now by the plug-in modernizer tool. But when we have to display the explore this repo or explore any plug-in for how the metadata tool uh modernizer tool has work on it. So we need to manually check each plug-in and each recipe reports which are in the JSON format in this report which is a very difficult task. So the idea of the plug-in mod stats is to display all this data through an UI site. So we have a GitHub action which aggregate all the data from this metadata repository into a single JSON file. You can see it here. So it contains all the recipes, all the recipes which includes the plug-in modernizer tool and all the plugins on which the tool has applied the recipes and on this JSON uh report.json JSON file we have built a UI site so which shows the overall status and all the recipes applied then the migration pipeline according to which the monthwise distribution according the success and failure of the tool. So let's see this is the dashboard page and currently the plugins and recipe page are in the progress. Okay, I'll be sharing my screen now. Yes, now you can. Okay. And the future plan is the completing the plug-in page and starting with the recipe page and adding more test cases parallely to improve the and also the improving documentation ensuring stability and future mentability and writing a blog about my midterm journal. Next slide. So yeah, this was the overall status and I was thankful thankful to my mentors for guiding me and also special thank you to to the infra team for giving me the guidance about the report.json and the GitHub pages to deploy. So I am free for any question also. Thank you. >> Yeah, that's so good Pratik. So anyone have any questions for Pratik? Yeah, Mark, I can see your handwriting. >> Could you share the URL to your GitHub page? And were there any things where you found, oh, this is really surprising what we learned from it? So, I'd like to see the URL. And then were there things that oh, I didn't expect that? Pratik, you're muted. Okay. So, I have sent the link of the UI site in the chat. You can open the link I have shared in the chat. >> Yes. And I was able to open it just great. Thank you. >> Okay. So, so the main purpose was s the timeline graph. So, it was not previously implemented. I implemented that and by seeing the stats according to the month wise. So, how this month there are the these are the success rate and this is the failure rate. Then next month this is the success rate and this is failure rate. So overall result was as the month is growing as we are growing moving forward the failure rate is declining. So as we move forward the plug-in modernize the tool success rate is increasing. So that was the exciting to me about the progress of the tool >> now. So for me, I look at the graph on recipe performance setup Jenkins file seems to have a surprising failure rate. Any insights there or is that something you didn't investigate? And that didn't investigate is perfectly fine. >> Yeah, I didn't investigate it till now, but making the visibility of the plug-in moder tool is my main task. So you get a question about that the setup genin files have setup genin file recipe has the more failure. So that was the purpose of this >> right. So the fact that we can see it is a success. >> Yeah >> the the fact that that data is presented to us is really great. Thank you. >> Perhaps I can answer on uh that one. Um, by experience, the setup Jenkins file is applied on very outdated plugins that sometimes don't even compile. So that's yeah quite difficult to uh to automate. uh what would be useful is uh if we have the the information for example about the last commit. If we can uh see a correlation between the last commit the date and the and the recipe and if we have this information we would see that uh those recipe are apply on very outdated plugin that might cause the the recipe to uh to fail. Well, and and it's it's the the graph shows one crucial point. 600 attempted plugins is a dramatic attempt, right? So that's that's what one quarter over 25% of all plugins. Nicely done. Yeah, happy to see that the UI site is helping the genkins community to see the overall progress of the tool. Yeah, that's it. Thank you. >> Yeah, thank you Mark. Thank you Valentine for adding your insights on the success rate. And next moving forward for the last for the day we have what's retool jenkins.io IO success stories with WhatsApp bar and WhatsApp over to you. >> Um thank you. So I am Watsil. Can you please uh do the next slide please? >> Okay. So I am Watsil and I'll be working on R2 Jenkinsio success story website as a GC contributor and my mentors are Kristen, Rajie and Jammud. Uh can we have next slide please? So this is how uh the presentation will go. So uh I'll be telling about myself and I will also be telling what genkins IO success story project is about and we'll be also covering what we'll be doing in this project and what is my current progress and we'll be also following up with a demo. Then we'll discuss about the challenges that I have faced or I'll be facing in future. Then we'll be discussing about the future work and we'll be taking some questions next. Okay. So uh let me tell you a bit about myself. So my name is Vatsula and currently I'm a final year B tech student at ABS engineering college Gazawad which is based in India. I am a passionate software developer. I like uh doing graphic designing and I am also a software uh I mean open source contributor. So I started contributing to genkins back in August 2025 and it has been a really very good journey. I have met a lot of good people and u very intelligent brains in here. So uh you can also check out my profiles uh which is my GitHub and LinkedIn. Next slide please. So uh what is stories.jenkins.io. So it is an uh official website of sharing success stories of genkins. So it showcases how the uh genkins has made changes in organizations how it has helped organization to make the CI/CD uh really very reliable and automate the software development and delivery. So currently like there are most more than uh 190 user stories which are shared all around the world uh to Jenkins. Next slide please. So uh this is the uh like introduction to the project. So this project uh actually aims to retool the genkins IO website success story from uh text which is Gatsby to uh react based architecture. So in order to like improve the developer experience performance etc. So uh why do we need to uh migrate away from Gatsby? So the reason is that uh Gatsby is not actively maintained right now and uh we are unable to move to the newer dependencies of um different npm packages because of which uh we are like failing uh getting some sort of unstability and we are not able to bump up the dependencies. Also uh let us talk about the key objectives of this project. We need to migrate from Gatsby to wheat as I have just mentioned. So uh we also need to uh fix the YAML files. There are approximately like 194 YAML files and there are inconsistencies, broken datas and uh like broken data we can say u like invalid punctuation and the structural problem etc. So we need to uh clean that up using uh some scripts. Also we need to redesign the story submission workflow which is currently using decap CMS and netify CMS. So we need to replace that with GitHub actions. And why do we need to do that? Because uh decap CMS and netify CMS is currently working as a content management system for stories.jenkenkins.io. But uh when it comes for a user to submit a new story then they are unable to do so because it requires some of like uh admin permissions. So we definitely definitely need to migrate away from it. So to have some new stories also we need to modernize the UIUX uh that we'll be doing in future and also we need to add up a testing layer and code quality tooling to ensure uh application stability. Next slide please. Okay. So uh here is our project progress what we have done up uh so far. So we have uh migrated the application from Gatsby to V. So uh which included like migrating the components uh their logic their structure from that of Gatsby to wheat and also we have set up the dynamic routing for 194 stories and for uh other pages as well and we are using uh vit SSD as a static site generation plug-in for vit which is uh improving our performance also we were using graphql data layer uh actually the Gatsby what it does it has a built-in graphql functionality so uh like we have migrated away from that. So we have decided to move forward with a different approach which is like diet yamel parsing using the beat features like metaglo and we are getting some expected results and also we have recreated the map functionality which is uh using leaflet integration. So this was the thing that I was talking about. We were unable to um bump up the dependency of leaflet and other uh npm packages because of which we were like getting some unstability. So also we need to uh maintain the performance factors and uh search engine optimization. Uh next slide please. Okay. So uh apart from the migration thing we have as mentioned we'll be doing the YAML fixes. So we have done these YAML fixes so far. So uh there were 194 user stories and out of them like 70% of them had like broken YL structure. So we had to clean that up. So we have audited and cleaned 194 YAML user uh stories. Uh most of them were done manually but we also did uh some build scripts and with the help of the scripts we cleaned some of the data which could be cleaned and we also removed some unknown and unused meta fields which uh were present in the uh user story files and also we have set up a yl lint in order to check for the structural problem in the yl file. So uh to have some consistency also we have used AGA and AGV format to ensure uh strict schema is being followed by all the user stories. So what AG will do it will check up for the fields uh if there is any unknown field then it will just uh return us a failure and can next slide please. So uh yeah so this is how uh this is the most basic structure I could think of that how our application is taking up the data. So we have uh YAML files from the source path. It is it is giving the raw AML to the data layer which is our util and uh the data layer is uh getting the raw YL and it is being converting to the JSON objects. So uh with the help of the JSON YAML npm package and it is like being fed to the web pages. Next slide please. Okay. Uh can I share my screen? Thank you. >> Yeah. Yeah. Now you can share your screen. >> Okay. Uh is my screen visible? >> Yes, it is. >> Okay. Uh so Okay. So, uh this is how our application looks like for now. This is the like initial phase. So, uh I would like to mention one thing that we'll be changing up the UI uh eventually in our uh UIUX phase. So this is how it looks like for now. So if you go to this page, we can see that we have user stories which are coming whose data is like coming from the YAML files and uh we have some u filters with which we can filter up the user stories and we also have some sort by functionality. Okay. If we are like opening one of the user stories then we can see how the user uh stories are structured. We have heading, we have subheadings and some of the metadata fields along with the user story image. Then we have body content of the uh which are coming directly from the YAML file. And then we have uh our testimonial component which is integrated in the story page itself. Uh apart from that we have also configured uh the uh footer actions like whenever we are clicking on any of the user story then it will redirect us to uh its source part with which we can like do any changes if we want to. then uh it can like create a PR right away. Apart from that, we have another functionality which is our uh map feature. So uh this is another feature that shows uh user stories all around the world which uh people have shared. So each pin you can see in here is a uh is a user user story which is shared. For example, we have a user story from India. when we click on it, we just get redirected to the actual user story that I just mentioned. And also if you don't want to um uh like choose a user story from the map, then you can also choose uh from the side panel. Uh if you click on a particular country, then it shows uh different user stories. If you click one of them, we get redirected uh redirected to the user story itself. Also, we have some filters uh according to the uh according to the industry. So if you click one of them then we get uh like the user story related to that industry. So uh this is what we have done. Okay let me stop sharing. Um can we have the slides please? Okay so uh what challenges I have faced and what I'll be facing. So uh I have replaced the graphql data layer. Uh so it was uh quite hectic task because YAML files parsing approach we were like moving with the YAML parsing directly. And uh there's a thing that uh YAML files are like sensitive and if there is one line code change or one line error in the YAML file then the whole application can break. So we had to handle that properly. Also uh the redesigning user story submission workflow that we will be doing in future. So we need to configure the custom GitHub action for that uh in order to get the expected results that uh and also for the redesigning the UI we need a lot of iterations that I think will be a hecky task as well. Next slide please. Okay. So uh future work as I mentioned that I'll be implementing and configuring the users to submission workflow using GitHub action. Also we need to improve the UIX and responsiveness adding test to ensure the application stability and I'll be continuing with the documentation of uh for guiding the users in order to submit the user story efficiently. Next slide please. Uh so uh are there any questions? Yeah, that's awesome. So, we have two more minutes for question for WhatsApp. If anyone have any questions, feel free to raise your hand, ask, unmute and do add it in the chat as well. >> So, Vatel Mark, wait here. Do you have do you have a prototype site running that we could link to and any any key things that you've seen where oh we ought to do this or that even better as we as we look forward the change from Gatsby to Vite seems to seems to be a smart one. What about when Vite becomes unmaintained etc. Um first of all yes I have a prototype it the version that I just shown uh was deployed one so I can share that as well in the chats and apart from that for your question that what if v gets maintained so for now uh if I taking the scenario that I don't think that it will happen but if in case that happens that we'll definitely be moving to a newer framework. >> Thank you. You're welcome. Also uh before uh going I would like to thank my mentors Kristen Jamud and Rajiv which are which have really been active and they have been guiding me so well and solving all of my problems whichever I had. So thank you for your guidance. Okay then I see no questions and thank you. Thank you. have a amazing friend. So guys, it is so wonderful to hear from all the mentors, contributors and the admins as well. And if you want to do check out more about what Jenkins is doing within the GOC or GOC within the Jenkins, there are so many resources for you or here in the slides. Feel free to check out that and being said that thank you everyone. Thank you for joining. Have a great day.