 Okay, it's recording now. Okay. Okay, we'll get started. All right. Hi everybody. Thank you for joining today's Jenkins online meetup. Our session today is on Jenkins in Google summer code. We're focusing on the final project demos. My name is Alyssa Tong and I'm one of the org admins for Jenkins in GSOC 2023. Also on this webinar with me are other org admins, Jean-Marc Mason, Chris Stern and Bruno Verrachten. Some of our GSOC mentors are also on this webinar along with GSOC contributors whom you will get to meet shortly. All right, number two, please. Yep. So the Jenkins online meetup is a community driven virtual platform. Our goal is to inform transfer knowledge and share all things Jenkins. We're always looking for speakers. So if you're interested in sharing your Jenkins story or having a compelling story, please do share with us via that last link on the screen. Slide three, please. Before we begin, a couple of housekeeping items. This session is being recorded. We will share the link on the meetup page after the event. For questions, please put them in the chat window throughout the presentation. Our presenters and mentors will respond to them accordingly. And as always, the code of conduct is fully enforced here. If you're not sure what it is, it's simply being respectful and being kind to one another. I'm going to hand it over to Jean-Marc to take it from here. Okay, thank you. Thank you for the introduction. I like the elephant or the code of conduct. Here, the agenda for today is as Lisa introduced, we're first going to do a short overview of this year's Google Summer of Code with Jenkins. We will then have a 10-minute presentation of the current state of all the projects with a demo by the contributors where they will share their experience. At the end of each presentation, we'll leave a couple of minutes, five minutes or questions, comments. And when the four presentations are completed, if we still have some time over, we can answer questions. Should we run out of time for that, please ask your question on the various channels that were mentioned. In the beginning, we will monitor them after the presentation. So these years, Jenkins, Google Summer of Code at Jenkins, it's the seventh year that we're participating. We had four projects running or new contributors and a lot of mentors that invested time as a team to complete all these projects. So we had one project that was dealing with the plugin modernized, the GitLab plugin modernization. Another one was dealing with adding additional probes to the plugin health score. We also had building Jenkins IO, our main information site with alternative tools and existing ones. And last and not least, we had also a project about preparing some quick starts, docker-based quick starts for Jenkins environment. All the projects are listed on the below link where you can see all the documentation and notes for each project. So here are the contributors. I fear that some of the pictures are a little bit dated. Some refresh will be required there. So we had Jekruti, part of the adventure Harsh, Bandit and Ashutosh all four joined from India on this year's Jenkins Google Summer of Code. So we're going to start with the project presentations. Remember, try to stick with 10 minutes per presentation. First one on the row is Ashutosh with a Docker-based Jenkins Quick Start example. The floor is yours. Hello everyone, I am Ashutosh. My project is Docker-based Jenkins Quick Start examples as John Mark said. And let's start with the presentation. Next slide please. Okay, let's see what's the problem this project aims to solve. Next slide please. Let me paint a picture for you guys. Let's say there is a new user who wants to experience Jenkins for the first time with Docker. Let's see what the user's first experience of Jenkins will look like right now. First they'll have to create a Docker network with a Docker network command. Then they'll have to use this scary looking command with a lot of arguments to create a Docker and Docker container. Next slide please. Then they'll have to build a custom Docker image with a Docker file with this command after which they'll need to run that custom image with this many arguments. The obvious one of which is that it's complex and intimidating steps which can be hindrance for beginner users. And another thing is that we use the same setup in the tutorials that are designed for beginner users to learn Jenkins. So it's a complex thing for in that because we need to create the make the barrier to enter to Jenkins as low as possible because they're here to learn about Jenkins, not how difficult Docker can be. And another part is that the setup comes with its own security risks with Docker and Docker which we like to avoid. So the main goal of the project is to simplify the user experience especially for the beginner users. Next slide please. Okay, let's see what we did in the first phase of the GSOC. During first phase we aim to accomplish this objective using scripts. We developed Jenkins init script, Jenkins tear down script to initiate and stop the container setup. We are using multi-container setup with Docker composed for controller and an agent and we've created another script for generating SH keys and another for cloning and forking the repository for the tutorials. And we also integrated the tutorials in the script itself so that we can run them with the keyword because the tutorials need custom Jenkins agent to run. So we have included that in the script itself. Next slide please. Okay, let's see what we accomplished in the phase two. Okay, so during phase two our main thing we needed to do was incorporate Windows in the project because the script we created before were not compatible with Windows without WSL. So that's where Docker composed profiles came into the picture and turned out to be the perfect solution for us. Because it lets us do the keep the same format we were using before of using a keyword after the after the command. So before user need to run Jenkins init then the Meevan keyword for Meevan tutorial. Now they'll use Docker compose up with the Meevan keyword to run the Meevan tutorial. Another part was integrating the remaining tutorials which includes Python, Python tutorial, Node tutorial and multi branch pipeline tutorial with the previous Meevan tutorial. And we are also not using Docker and Docker in any tutorial now. So that's plus. And another big part of the project was automated testing which introduced me to GitHub actions. I didn't know GitHub actions before so I needed to learn it. And now we are using GitHub actions to test all the Docker compose files and upload the Docker images to the Docker hub and updating the plugins and testing all the tutorials. By driving them. Next slide please. And yes, everything works with Gitpod with just a click. Next slide please. Okay, let's see in a demo of everything I've talked about actually works. Yeah, can you do the necessary voodoo. So you just stop sharing your screen, John Mark. Okay. Done. There we go. Can you see me, my screen. Yes, yes, we can. Okay, so this is the Gitpod button. This is the repository that we are using. You can check it out. And while Gitpod space has been creating, let me show you the documentation that is present right now. So this is the Python tutorial we'll perform today. Here it's just the setup for Docker with Jenkins. So it's quite complicated as you can see. Gitpod is starting. And another thing is, let me explain you the tutorial itself. In tutorial, we need to fork and clone this repository, which I've already done and push a Jenkins file to it, which I've already done. So we'll just need to copy this link. Okay, Gitpod is taking some time. All the demo effect. Taking unusually long. Okay, this one is ready. So we'll do obtains gaps. Docker composed. And we'll do Python. Python is the keyword for the Python tutorial. And it's pulling the images. Right now we are using the pre-built images in our tutorial. So this is the only command that someone who wants to try out the tutorial needs to type. Yes, before it was this whole. Now it's only Docker composed up with the name of the tutorial. Okay, Jenkins is starting. Let's open the preview. And we also intend to add a Gitpod button that users can just one click and use Jenkins. Okay, let's log in. Okay, let's capture. We have added a simple demo job in it. Let's create the tutorial. We are using multi-branch pipeline for all the tutorials from now on. Let's add the source. Source is the link for the repository. It's my personal repository, which I've opened and flown. So it will scan for branches. It should only find one branch. Okay, it should run any second now. As you can see, it's running on the agent container and not the controller. And we have also added pipeline graphy plugin instead of blue ocean plugin since it's been deprecated. So this is the closest we got to that. So as you can see, it's completed successfully. Okay, I'll stop my screen now. Go ahead and share representation again. Next slide. What time is completed? Yes. Okay. Okay, and let's see what I learned during the talk. As you can see, there's a lot of things, which includes great GitHub best practices, GitHub actions, how to write Docker compose files, how to write shell scripts, and so on and things. Next slide, please. Okay, let's see what's next for the project. We intend to transition from GitHub actions to CI dot Jenkins dot IO. We are in talks with the infras team right now for doing that, after which we'll be able to fully integrate this into our project into Jenkins dot IO. And we hope to do it before October. So we can incorporate the repository into Hacktoberfest with good first issue to engage beginner contributors to. And as a stretch goal, we might expand the project with additional tutorials in the future. Next slide, please. That's also a good goal for people that want to participate to Hacktoberfest. Okay, go ahead. I'd like to thank my mentors and John Mark Bruno and Vivianto, especially for teaching me and helping me learn so many new things and Jenkins community for their support. Next slide, please. Okay, if you have any questions. You managed to do the demonstration presentation 10 minutes. Yes, I've practiced it before. Are there questions I've seen QA Bruno, can you eventually? Yes, of course. So not only must attend the asked, will we have access to the recording session afterwards. And the answer is yes, of course, Lisa, I think it will be part of the meet a page later on. And I guess there will be a post on community Jenkins.io maybe the on Jenkins, it will be on. Yes, community Jenkins.io. Yes, it'll be there as well. Thank you. And then we have Aaron Conaway asked how can others submit tutorials to include. I could answer live but I will do it first and then I should just maybe you'll say something about that. We have a guitar channel just about this project. So I guess this would be the right place to ask, or it could be on community Jenkins.io or Ashutosh. And you can directly ask on GitHub itself and the repository you can create create an issue and get a channel. I think that the channel will be the best for suggesting a tutorial. Yeah, let me try to find the link and post it into the answer. Okay. I think it's at the end of the presentation. I'm not sure though. Okay. Okay, good. Are there other questions? I'm not used to that interface here. See the chat. I'm not seeing any other questions. Okay. I have a question to Ashutosh. What was your channel experience of Google Summer of Code? Was it scary, exciting, tiring, accelerating? So choose a word and tell us what was your experience? It was all of them actually. At some point it was scary, some point it was. Yeah, it was all of them. It was really good journey and I enjoyed it very much. Good. Great. Thank you for sharing your experience. Thank you for the work done. I see it as a great simplification so that people can immediately start experimenting with Jenkins and have everything set up and look for the infrastructure. Ashutosh, thank you very much for your participation, for your presentation and answering the various questions. So we'll move to the next presenter. And the next presenter is Vendit. Vendit was going to tell us about what he did to be able to build Jenkins IO with alternative tools. Floor is yours. You're on mute, Vendit. We can't hear you. No, no, here's a sound problem. You can try with hand signals, but it will not work. Can you hear me now? Yes. Yes, now it works great. Sorry for the problem. Hello everyone. Hello everyone, my name is Vendit Singh and I'm the Selective GSOC contributor for this project. And we are rebuilding Jenkins.io with alternative tools. Next slide, next slide please. So something about me, my name is Vendit Singh. I'm from India. I'm currently pursuing computer science and I have interest in many technologies and I love building stuff. I love open source because it's cool and it will take over proprietary software in the near future. And I love connecting with strangers and working with them. Next slide please. So let's talk about what the project is about. So the project is about rebuilding Jenkins.io, but so the first question that comes to someone's mind is why are we rebuilding it? So next slide please. So we need to know something about Ostrich and Jenkins.io and their relationship. So Ostrich was the static site generator that was used to create and develop Jenkins.io. But it has been totally under maintained since last two years and people from Jenkins community are helping it and maintaining it. So since it is really under maintained, it was a good move to something new which is maintained which will not break in the near future. Also Jenkins.io documentation required versioning and we could not do that with Ostrich. So we had to move to a new tool that could help us in versioning documentation out of the box. Next slide please. So this is the table of content about the things that you are going to. I have completed the project description. Next slide please. I think I'll just go on and we'll see. So we'll be using Entora and Gatsby to rebuild Jenkins.io. So if you are watching this presentation, you will get this question in your mind that why are we using Entora and why are we using Gatsby? Only these two tools to rebuild Jenkins.io. So next slide please. Next slide. Yep. So we are using Entora because it implements versioning out of the box. And the main major part of the Jenkins.io consists of documentation that is used by users and developers throughout the world. So we wanted it to be versioned because in some part in some versions of Jenkins.io you don't have some features but in some versions you have something. So it was a needed feature that everybody wanted. And Entora uses AsciiDoc files to serve the pages. And we have AsciiDoc files, a lot of AsciiDoc files on Jenkins.io for the documentation. Then we are using Gatsby. We are using Gatsby because it has really fast build. It's secure. And we wanted we are using Gatsby only for the blog section and some pages, some single pages because like and since Gatsby uses GraphQL. So that was also a plus point for us because we wanted to we wanted it to be fast to faster than before. Next slide please. So the achieved milestones we have done till now are we have completed the documentation site with Entora that you will see in the demo. We are still working on the blogs like we have completed it, but we still have the blog's milestone consists of some two to three more pages like the landing page, the download page, the change log page. We are still working on them and they will be done in the near future before the before the extended coding period ends. So some some pages will be done by 20 September. That is what we are that is upper limit that we have a thought talk. Next slide please. Yeah, so I'll show you what I have done because I won't I won't believe some if someone says that he has done he or she has done this business. So normal. You can start sharing your screen. Can you guys see my screen. Yes. Awesome. We don't hear you anymore. You touched the wrong button. Can you hear me now now it works now it works. I don't know what's happening, but let's go. So we are using Entora for the versioning. And you can see here that we have we can switch between versions. Currently these are the demo versions because versioning will be implemented from now on from now on every time a new LTS release that is released after I guess every 12 four weeks. So we will have we will have a new version and you would be able to see in the user documentation if something is something is added in the new version. So that would be with the help of this drop down. And then we have the sidebar we have we have focused on the UI and UX so to increase increase the UI user experience of the users of Jenkins.io. So user documentation is versioned. Another documentation that is really important was developer documentation, which is non versioned because when you are when you are maintaining source code you don't you don't want to you get the history on GitHub so you don't need to have it on the site and it is not it is not needed. So we have a developer documentation which is not versioned when when something which is non versioned you won't see the drop down. And you can also you can also switch from here to you can also switch from here to the pages that are versioned and not also to access different pages of Jenkins.io you can you can access this drop down and and access them. So this this was all for this was all for the entire site if then we come to the Gatsby site that I created for the blogs is this currently it is following the theme and feel of Jenkins blogs that continuous blogs. So it we will we still have to add the author's name and their links. And if you go inside one of these we still have to style we will still have to style some parts of the inside blog and add the author images and the end and if you go down on Jenkins.io you have the about the author section where you will have a small description of the author and their links. We still have to add that from here you would go you can access the blogs page in the near future of you can access the author's page in the near future. And if I just go to authors. Yeah, so here's currently we are using a demo dummy image right now but when the project will be completed you will have will have the submitted photo of the contributors that contribute to the blog. So this would be the this would be the community blog contributors page and you can you can access them but they don't have anything right now because we are still we are still working on the authors six side of things on blog. After that, after that we are still working on the landing pages and they are still not yet to be shown and completed. So that was all from my side for the demo. I'll stop my share sharing. Yeah, you can hear me right you can hear me right. Yes, it works. So, next slide please. Yeah, we are. Okay, so when you are working on a project, there's a definite there's a possibility that you may not face any problems what we did. So, when before before in the first phase we asked the community what they thought about the project structure and the plan, and it was suggested that we use trappy with Gatsby for the back end as a CMS, but we tried we tried using it but and it was not. Okay, with the infrety man as that would be server side rendering, it was it would use server side rendering and that would take a lot of resources. So that's that was the one of the issue using strappy with Gatsby. The other thing was there on in the in the site you would see many links and how austra used links for linking is completely different than how entora does it. So we had to automate we had to write scripts for it, and Chris helped me a lot with it. So we work we fix the interface linking back to that and then we went to the data table API on some pages we have the data table API that which is tables from the table data from the table API for Jenkins. That was not working and it was using Ruby. So that is not something I'm very good with. So Chris turn really helped me use my winter. Next slide please. Okay, so after the project I have after the project to till this phase I have some key takeaways that I need to share with people so they can get they can they can just learn it. So Jenkins.io is a really large codebase for the Jenkins.io so migrating that was we really needed a lot of planning and and after the planning you would have to see to the execution is going well too. So the my mentors really helped me in planning of things how to do things. So that thank you mentors for thank you my man thank I'm thanking my mentors for that. Another thing I learned from was that I learned a lot of a lot about entora gaps we graph kill a lot of a lot of scripts I learned a lot about regular expressions while doing that. Also, I've realized the importance of community feedback as well because community knows a lot of people in community are really great developers and they know a lot. So they really helped me in expanding my horizon and think about other things too. Next slide please. So thank you for so you can you can connect you can connect and learn more about the project from the GitHub channel and the GitHub link is there and the icons I stole from Ashutosh presentation. So that was all from my side. Do you have any questions? We're going to see. Thank you very much for presentation demo. I'm going to stop sharing here. Are there any questions? So for the timing I can see any question directly linked to Vandy's presentation. But hey, there is a more general global question. Vandy it in a short short question is why did you need extended coding period why did we have to extend. Can you explain a couple words? Yeah, when we experimented with Strapi that took up a lot of times around two to three weeks. So if you didn't have to work with Strapi it would have been completed by now but it was a really great option suggested by the community and the developers in it. So we had to try it out. So that was that eight up some time so that's why I had to extend my time period to complete the project. And you had also some school related constraints during the summer and it's so needed to balance. Yep. Okay. Listening if there are questions otherwise I have another one. Bruno you chime in if we we have the only question we had was not directly linked. As I said it was from Betty Betty Gupta who was asking I'm completely new here and I want if I wanted to get into how and what things should I have to know. The thing is I don't know if this is Jenkins related or GSOC for Jenkins related. So if it's for Jenkins, I like your image the one you use most regularly is a mark which is build your Jenkins muscles. So the thing is you have to start somewhere you have to know more about the Jenkins community the Jenkins project and so on. So most of the things you should do is talk with people discuss on one of the matrix channel for example Jenkins CI newcomer contributors. The place to be when you start. There is also a page on Jenkins.io, which is Jenkins.io slash participate, which will is a few ways of participating in Jenkins. It's not always code. It can be participating in the forum, writing documentation, writing blog post, participating in meetings, for example, giving your feedback as an end user, for example, lots of ways to participate in Jenkins. And Aktoberfest is just around the corner. So maybe have a look on issues tagged with what is it, John Mark? Good first issue or something like that. Good first issues. And we're going to explain that more in detail. Stay tuned for that. I have a last question to Vendit, otherwise we're going to run. Yeah, go ahead. Vendit, how did you feel with Google Summer Code? I like this question. The same question as to Ashutosh. Can you tell us in a few words what was and what you would like to share with the people that will follow you? Okay, so when I started my project, I was a bit scared. I was a bit, I was a bit, I don't know. I was, I was, it was scary. The experience was scary when you're starting something. So because I didn't know anything about Endora, I didn't know anything about Gatsby. I didn't, I didn't even know about GraphQL that I used. So after, but when you dive in into things, when you just start things, it, it slows down things get easier and easier and you start and you have something to showcase in two demos that you have over the summer. So it was a really nice experience and I really loved the journey. And so you would also recommend people to start preparing and compete for GSOC? Yeah, I would definitely recommend that you start with Jenkins because it is a really great community. We have really empathetic people in the forum in the community. So it is a really great place to start if you are planning for GSOC 24. Okay, good. Thank you for the kind words and open source is a great way to complement what you learn in the school. It gives you practical experience. Okay, thank you. I'm, I'm slowly getting through the different presentation. The third presentation we have now is harsh. Harsh worked on the GitLab plugin modernization and quite some, some work to do there. Floor is yours. I'm not sharing my screen. Yeah, I think the slides are not shared yet. Yeah, agreed. Are they okay now? Yes. Okay, go ahead. So hi there. Warm greetings wherever you are. This is the final presentation for the GitLab plugin modernization project. I am Harsh and my mentors are Mark, Basil, Chris and Freyam. Next slide please. So a bit more about me. My interest slide a lot of weird computer science feeds like cloud native cloud native technologies and modular blockchains and whatnot. And I'm also interested in weird non-technical fields like economics, philosophies and I love reading books whenever I get some free time. I'm currently in my sophomore year at the Indian Institute of Technology Kanpur and I started contributing to Jenkins in my freshman year from February 23 and I am hooked since then. So if you want, you can check me out on Twitter and also my GitHub. Next slide please. So yeah, about the project. So, GitLab is a modern DevSecOps tools, a tool which is quite fast growing in nature and mark my words, it grows really fast. So, Jenkins GitLab plugin provides a seamless integration of GitLab with Jenkins, but unfortunately it was not able to keep up with GitLab space of evolution over the past years. Thus, GitLab plugin modernization project was very much required and we migrated the plugin from old REST easy library to GitLab4j API. And this was particularly useful because the migration fairly reduced the maintenance burden that we were going to have later if we would have used the REST easy. It made the plugin much more lightweight because GitLab4j abstracted away a lot of external dependencies that REST easy was forcing us to have. It improved the consistency with all the other Jenkins plugins and also the other GitLab related plugins and it also improved the documentation quite a lot for anyone who's going to contribute to the GitLab plugin again. So let me brief you with my journey in the community. So next slide please. Okay, so my journey was an adventurous one to say the least. I started contributing to Jenkins when I just had around one to two months of programming experience in Java. And from being a very curious ubiquitous to now being a maintainer of the GitLab plugin, I think I've come in a very, very long way. I learned a lot of technical and as well as non-technical things. Like GitHub and most importantly GitLab, CI CDs and whatnot, extensive debugging and even inside the Docker containers. I developed more stronger programming concepts of Java and object-oriented programming. I learned about Docker-based functional testing. I learned about Proxies and Nginx Proxies, Apache web servers and whatnot. I learned about REST APIs, HTTP requests, but multitudes of networking concepts. I learned about planning and executing a project end-to-end, which I think is the most important thing that I learned out of the project. Keeping in mind the maintenance over the long term, I learned about UML diagrams and whatnot to make the planning happen. And I would really just thank Jenkins community for providing me this opportunity as it helped me learn a lot of things in a very short amount of time. Next slide please. We wanted the migration to be like magic, but unfortunately it's not. I emphasized GitLab grows very fast. So it has the plugin used to support version 3 and version 4. But as GitLab has evolved, we are going to drop the support for version 3 as GitLab is not supporting version 3 right now. And this version 4 will only be supported by the plugin once the plugin is released. Also, GitLab 16 included some breaking changes that we will have to tackle. And it's a particularly difficult situation to tackle right now. That's why we are still working on it. But we are not accelerating our work because we want to take our time to make sure the plugin is tested extremely well with lower Jenkins version as well. And we'll also have to make sure that the plugin is compatible with older GitLab versions, which is quite a far-fetched goal yet. So we are working on that for using the modernized plugin. The minimum Jenkins version will be 2.387.3. So next slide please. Okay, so let me show you what the plugin can do. Be able to share a screen now. Is it visible? Not yet. Not yet. Okay. Now I think it should be showing. Yep. Okay. So I've already set up and set up my Jenkins container and I am using the production GitLab server. So I will be committing a change like some weird things that I've been doing before. And let's just commit it. I've set up a freestyle job in my Jenkins instance and the GitLab sample job is triggered. So it will be working and let's see the pending right now. Yeah. So let's see the console output. Taking a bit of time. Okay. I had a lot of things that's fine. It's working a bit. Yep. So it's a success. And let's see the changes. The changes show the commit that I made in my GitLab repository. So yeah, that was about the demo. It works perfectly well. Some things are missing. Like, Can you share the slide again? Yep. Should start showing. Yeah. So some things have to be worked upon again. Like we are currently doing the interactive testing a bit more so that we can be sure that the plugin once released is working the way it should be. Yeah. If you know, next slide please. Yeah. So if you're more curious about the project, it seems to be working right. You can learn more about the project on the project page. You can join us for the project discussions on the GitHub channel. You can see the project notes. And if you want to refer to the project architecture, how the architecture of the GitLab plugin changed due to the change in the library. It was a major one. So you can check the project meetings as well as the recordings. If you want to see the code file an issue or you have any request, you can just go to GitHub repository link and just file an issue. Next slide please. So thank you very, very much. Question to my lovely mentors, the supportive community, to the org admins and for your patient. Next slide please. So if you have any questions, you can ask right now. It's the perfect opportunity. Don't shy away. Hey, good. Are there any. None that I can see showing here. No. No, not for the same being so harsh. Same question as for the others. What was your feeling? You already explained a few things. You learned a lot in that. And I love the journey analogy. How was your feeling? And would you recommend others doing it? Some things in life, you just have to experience the words don't match the expectations actually. So contributing to open source is one such thing. Like if you experience the warmth of the community that you get to experience once you start contributing to open source, you, you will understand what I meant when you, when you hear me. But in, if you want to get it in one word, it was simply adventurous. Like it was scary. It was great. And it requires a lot of planning. A lot of help by mentors without them. I don't think so you will be able to get up to the speed. And a lot of support given by the community. And a very warm environment for you to nourish yourself to learn a lot of things. Not like contributing to Jenkins is going to help you in ways you don't even know. Like I also contribute to other open source communities. And it has helped me a lot because it has made me quite a fearless person. Like I can simply dive into the code because code base because I've managed and debug like specifically debug so many libraries and so many things that I am specifically fearless about it. So it will help you make your mindset a bit stronger and focus on the word building the muscle. It is actually very important. Once you build the muscle for one open source project, you are going to have that muscle memory for almost all open source projects. So you will be easily able to contribute if you just put in the time. I really emphasize people to contribute to open source. Hacktoberfest is really like coming soon. So simply contribute if you want to have fun of an experience and Google Summer of Code is great. But don't take it as a competition specifically. Like don't take Google Summer of Code as a competition. It is a very beautiful thing because even if you don't get selected, you are going to learn a lot of things. A lot of things. I have a small question before giving the word to Jakruti, who was waiting for her part. I remember that when we had the first discussions, what GSOC was and so on, I compared it to mountaineering. The adventure of mountaineering, where you need to train, where you need to, there are a lot of dimensions in it. So there is also you need somebody to help you. You need to rely on your, was that analogy correct? I have seen some heads nodding there. Is that something that reflects what it is? It's kind of a snowy mountain. Like when you start climbing the mountain, the rocks are rugged and you just have to put a lot of effort just to get started on where the hell should I get my first commit. And once you start going, it feels very smooth. So once you get on the top, it can get slippery. And it can get slippery because either you planned wrong. Like one day it happened with one of the right, it tried stuff and it failed. So it can get slippery. Another thing is you have to be ready constantly to put efforts until and unless you reach at the top, not to slack off in between. Like it just happens. Motivation goes down after the coding phase one a bit and then you have to pick it up again. And then you have to go back to the place. They help you a lot. Okay. So with this, something we may, may eventually come back. One of the summary I made here, it's a great adventure. It requires work. And it requires a lot of dedication to do. So I've seen there is a question there. I will first want to have Jakruti make her presentation. And then we'll come back to more general presentation. So Jakruti, you're still on mute. Yes. So this is your presentation. Go ahead. The floor is yours. I think I should take the control of the screen. Say that again. Yeah, I mean, I should take the control of the screen because I do not have a demo to demonstrate. Oh, you're fine. Yeah. Yeah. Yeah. John Mark can, can. Stop share. And so you can share your screen. Okay. So I've shared my screen now. Yes, we can. Great. And we're seeing it. Okay. Hello everyone. I'm Jakruti. And my project for GSOP 2023 is adding groups to plug in the health core system. My mentors are Adrian, Antoine, Jay, and Payam. So the agenda of this presentation will be, I'll start with telling something a little about myself that I will tell about my project. I will also say, why did I pick this project? What did I work in the past three months? What did I learn? And the future plans for open source contribution. So I have a full-time job. I'm a senior political junior. I have a few years of experience under me. I started contributing to open source project in last year, 2022. I was afraid of not developing new skills and getting staff at work. So I'm grateful for the community to give me an opportunity and also to my mentors for guiding me. So what does plug-in health core project all about? This is actually a system that rates the different plugins based on what good practices they follow defined by the community. We have probes and probes are nothing but different kind of system that collect data about each plug-in. Probe computes the score of the plug-in. And then we rate the plug-in. A plug-in that has a higher quality is given higher score and a plug-in that is obsolete is given all over school. So why did I pick this project? When I started to prepare for my proposal, I actually was looking to strengthen the skills that I already have. And this project was the correct fit for me because it was in poor Java and I already do work in Java. So that is why I picked this project. Also when I was asking questions, discussing things in community, they were really helpful to me. They solved all my doubts and I was getting a deep understanding of the project. I also really wanted to learn some class design and all these opportunities were provided to me by the project. In the first part of GSOC, I worked on three different probes. The first probe was used to detect the unreleased production changes that have not been published yet. The second one detected the third-party repositories that are being used by the plug-ins. The second probe that I had worked on actually detected that the GitHub actions do have the specifications provided by the check-in security team and they are executed in each of the plug-ins. This is the first probe that I started with. The second part of GSOC, the renovate probe is actually nothing but a bot and checking community encourages us to implement in new supports like dependent and renovate to automate the dependency update. It is important that not just we use the bots but we also take care of the plug-in, of the whole request that came. The challenges I faced and the things that I learned was code refactoring which is really important in the contribution. My challenge was to avoid code duplication and also to write a readable and maintainable code. The current status of PR is that it is merged. This is another exciting probe that I had worked on. It didn't make me scratch my head a lot. This is the number of open issues probe. This probe actually what it does is actually calculates the number of issues opened in GitHub and Jira. These are the two issue trackers that are used in the plug-ins. It is important to note the number of issues open because if there are a lot of issues open in a plug-in it might mean that a plug-in needs maintenance or it is inactive or dead. The challenges were to avoid a lot of fortification and getting the correct level of factorization in the code because as both the plug-ins as both the issue trackers GitHub and Jira they used the same details. We had to get the same details but the API and the library is used to fetch these details who are different. The importance of this probe is it tells you that okay, some have a lot of issues so maybe they require adoption or they have more number of active users so they require more contributors. The current status of this probe is that it is under review. We have computed the functionality but we are trying to make it more maintainable and future. An incremental build detection probe Explore what I have understood is that to build parallel development components is actually a little wortism so this is actually a tool that aids in the development. It does not really deploy all the modules at a time it really deploys a module that are affected by new comments. Okay, so this was a completely new thing that I got to know that is actually implemented in the plug-ins. So I first had to understand it and then identify how to correctly actually need to correctly collect the data from the plug-ins in my group. So this probe is also one of the worst probes. The next probe was to detecting deprecate JSR 305 imports in the probe. This is nothing but the JSR is actually a Java specification request which has different kinds of requests or libraries you can say. So what we use in the plug-ins is not men and check for null annotations. The thing is these annotations have actually been deprecated since 2016 and they are not maintained anymore. So it is not at all recommended to use these annotations. So this probe actually highlights and identifies that it will be your plug-in. This is the rotation and you might need to change it. This is also one of the merged probes. This is a quick visualization of what I actually did during the soft period for the three to four months. When I started the project, it had 14 existing probes and I added a seven probe. So the total count of the probes that a project now has is 21. The things that I worked on along with building new probes is working on the bug fixes. This bug fix, one of the bug fix was in XCN link validation probe where I have to take care of the link had some difficulties in the regular expression. So I wrote blogs for almost each of my probe and there is a new prototype that we are building to generate effective form files. This is what I'm working on right now. My future plan include to work on the effective form service and maybe maintain it in future. I want to be as active as possible in the community and there are different repositories in Jenkins that I have not explored yet. I would like to explore them as well and maybe mentor new contributors. So what did I learn in open source? There are a lot of things to learn but the most important thing is communication part. As we all know that open source really relies on written communication on communication channels like Gitter, Slack or maybe commenting on your GitHub address. So it is important that communication is clear. It is always encouraged. I was always encouraged when mentors and lawyers had to be autonomous, this is really important. You should understand the topics and research them on your own before asking a lot of questions. It is also important that we write a readable and maintainable code because my mentors always said that maybe you are contributing now and why not be the same maintainer in future. So you should always write Java docs and collect the code for better documentation in future. It is also important that how we handle criticism. I remember there was an instance where I always had to work, redo my six to 30% of the code which was number of open issues because I had incorrect class design. So it is important that we take it positively and understand where it is coming from. The mentors are saying what they are saying and to take the correct steps to implement them. Also, there was another instance where one of the members of the community just commented on my probe that I never knew before that I should pick this approach and this approach might not give desired results to my probe. So I simply went ahead and implemented whatever the number was saying instead of really arguing or anything like that. Even though I did not really understand completely why they are making that particular point I didn't understand it partially but I did went ahead and collaborate. The next thing is I also learned new approaches like one of the things I learned to think about is how to think of test cases before starting to code. This is something new which I had never done before and was suggested by my mentors strongly and I should start with test cases to actually write the code. Okay, so if I have to start with open source contributor as a new contributor like last year like I did I would just tell myself not to be afraid of the humongous project and don't let imposter syndrome win. Do not think that these people are more experienced or more experienced than me or better than me. This is not really the case. Everyone has to start somewhere. So start with whatever you understand and not be afraid to comment and not be afraid to ask questions. GSOC is just a journey. It is not the end. It is just a beginning where you can get guidance and leadership to start to contribute in the business projects but there are a number of projects and a lot of things that you can do and open source. It is all about the community. Community is something that you have to be interdependent with most of the ourselves question and interaction you will have is always with the community. So it is important that you are nice and respectful to them. Okay, so that was all from my side and I am now open to taking questions. Okay. I see a first question from Ulrich Hafner. Are the results of the probes already integrated in our plugin page? Or how can I create... So let's first answer that question. Jakruti, are the probes already available and accounted for? Not really. All the probes are not yet rated and limited in the storing system because my mentors told me that they are doing a major refactoring. So in the last meeting they didn't told me that it will be done in a week or so. There are some changes in the in the structure of the probes. The second question from Ulrich was Ulrich, how can I or how can I create the probes for my plugin? Is there something required in the probes... not in the probes, in the plugins so that the probes work? No, there is no such thing particularly required in the plugin. You should already know that what detail you want to collect about your plugin and how you want to do that and then you can simply implement it with simple writing a class and using a Java tool. Is it possible to try run a probe on your plugin or do you need them to be available in the system and to have the system run it on it? So can you do a lab test of a new probe? I'm not very sure about try run because to test a probe I usually write the test cases just recreate the scenario that is already existing in your plugin. So I think writing test cases will suffice. Maybe the vendors can say more about this. Okay. Because Ulrich is maintaining several plugins and it's really a useful feature to help and guide plugin maintainers. Are there other questions? I've seen people raising the hand to ask questions during the presentation. Don't forget that the way to ask question is either via the chat or via the Q&A. Jean-Marc, do you want me to share just a few additional information about the probes? Oh, yeah, sure. Yeah, yeah. Go ahead. Okay, awesome. So just a few additions on that. The probes are only a part of the plugin's scoring mechanism. So the probes are just a part which is gathering data, quality data about the plugins. And then another part of the platform is about scoring things and like computing scores out of this information. So while it is possible to run probes on a specific plugin it's a little bit of a hacky situation but it's definitely possible. Running the probes only gives you data. It only extracts data out of your plugin. And then there is the other part that you need to run which is about computing a score for that. So I guess the best way for that is to reach out to Adrien possibly on GitHub. There might be a channel for that if you want to do something. After the creating probes for specific plugins probes are actually meant to be shared by all of the plugins. They are supposed to be like collecting information out of all plugins and then there is supposed to be a shared common approach to evaluate the plugins quality. So Ulrich, if you have any ideas of quality metrics that should be added, I'm sure you can create issues, raise pro requests or reach out on Gitter to discuss with Adrien who is leading that project to integrate additional probes but they wouldn't be just for your plugin they would be for all of the plugins. Okay, thank you. I will ask Jakruti to stop sharing her screen so that I can finish because we're over time and I hate that. I'm just going to share the screen for the conclusion and we're going to see where it works. So this brings Google Summer of Code 2023 to an end. Jakruti and Vandit have still a few days to complete things and tidy things up. Still a lot of work to do. Oktoberfest is a good opportunity to help there. So it was a great experience a journey and the journey is more important than reaching the end because you never reach the end and so it was a great adventure. It will probably be the last one is Lead OrgAdmin for me. We're going to build a new OrgAdmin team for next year. I will stay around just for full disclosure. I'm going to retire very soon and my wife doesn't want me to spend so much time with computers and work related things but I'll stick around I like what we've been doing here. So we're slowly preparing with the new OrgAdmin team preparing Google summer of code 2024 so the Jenkins project tends to apply to the program in order to apply and be credible for that we need mentors and we need project ideas and this is what we missed the most this year. It takes a lot of work it is gratifying but it's a long run and we need people and we need a team for that. There were some good projects with a lot of people that worked on the project that we had to cancel very late in the preparation because we didn't have the mentorship for that and we owe that to the people the contributors that want to work on that that have a correct and good coaching in the project so this is it's really a call for action there. Project ideas, discussions and so on will start end of October beginning of November stay tuned on the channel listen there are documents explaining what, how read everything that has been published in all the recordings we made for the 2023 campaign a lot of things are there to be learned so stay tuned listen community members that want to mentor or have project ideas that could be a good fit reach out to the org admin team through the various channels that are available couple of resources here look at the Google summer of code meetings we had a lot of fun so don't stop all on the stupid jokes that I made during the numerous meetings we had but there's a lot of things to learn in there important event that we're going to hold with the Jenkins community is Hacktoberfest Hacktoberfest is a good event if you want to learn what contributing is read there's a lot of guidance available there people from the community should be available to help you good way to learn this is the way Jakruti started last year for instance other people also will learn it that way we have also DevOps world tour going different places around the world and you can have a discount code if you want to attend it and last but not least there is being Belgium I'm proud to say that we have the open source conference FOSDEM that will happen beginning of February in Brussels it's a free conference just need to get over to Belgium and find a place a couch to crash on somewhere food and rest we're going to supply there's plenty of that around there it's a great experience and we're probably going to hold a contributors summit for the Jenkins community there these are the upcoming Jenkins event thank you very much I'd like to thank the contributors personally thank the contributors and the mentors that participated with us to make this a successful year an interesting human experience I wish you all a nice and continuing journey with Jenkins and in your professional career and hope to meet you again in the community there's a lot of work to do in Jenkins but also other open source projects so we're way overboard so I fear we won't have time for additional questions so the only recommendation I have is other questions about Google Summer Code 2023 24 other events, Hacktoberfest go on the various chats and channels that we mentioned during the presentation thank you very much for attending and have a nice rest of the day wherever you are around the world bye bye everybody then thanks everybody bye bye bye bye