 Webinars being recorded. Great. So we'll get started. Hi, everybody. Thank you for joining today's Jenkins online meetup. Our session today is on Jenkins in Google Summer of Code. We're focusing on coding midterm demos. My name is Alyssa Tong and I'm one of the org admins for this year's GSOC. Also on the call are our other org admins, Jean-Marc Mason, Chris Stern, and Bruno Verrockton. Before we begin, just a couple of housekeeping items. Jenkins online meetup is a community driven online platform. Our goal is to inform, transfer knowledge and share all things Jenkins. We are always looking for speakers. So if you have a compelling Jenkins story to share with us, please do reach out via the Looking for Speakers link here. Here we go. So as I mentioned earlier, this session is being recorded and we will share the recording link after the event. So later on today. If you have any questions, please put your questions in the chat window or presenters and mentors will respond to them throughout the presentation. And of course, lastly, the Jenkins Code of Conduct is fully enforced on this channel and throughout the community. If you're not sure what that's about, take a look at the elephant in the cat picture and basically being respectful and kind to one another. So Jean-Marc. All right. So I will lead this session here. So I'm going to do a very small introduction what GSOC is and especially Jenkins in GSOC. We're going to follow the following format. This participant will present his project and probably do a demo of his project in 10 minutes and we will keep five minutes just after his presentation for Q&A question. And that will move to the next contributor. So this is a format where we're going to use. Next slide. So Google Summer Code is a program organized by Google, sponsored by Google to promote participation in open source programming and to train new contributors to open source. Next slide. So this is the seventh year that we're participating. We have four projects that have been selected in between six, more than 60 proposals. And four projects and contributors have been selected. Check out the main page referenced on the slide where you'll have details on the program and contributors participating to this year's program. And you will have also a lot of indication how to prepare for next year's edition. You can also review last year's participation and see what great stuff has been contributed to the Jenkins community. So we'll start the presentations. These are the four contributors that participate this year. And we'll start with Jakruti's contribution. So the first six weeks of participation, what she's already done and I think she has great stuff to present. Jakruti, the floor is yours. Hey, you can start sharing. Yeah, I'm sharing my screen. My screen is shared. Yes, see your screen. Okay. Hello, everyone. I'm Jabruti. And for this GSOC, I'm working on at Props to plug-in health care project. My lovely mentors are Adrian, Thiraj, Sheikh, Antoine and Pia. And look at the project in this website. My agenda for this presentation would be that I would start with explaining about the plug-in health care project. I will then introduce myself. I will speak up to three groups that I've worked on in the first part that is under these production changes. And then I will also speak about what I want to do in the second half of the GSOC and what I will do in that part. So what does plug-in health care project all about? As we all know that Jenkins is a round or two-ticket old project and a project that is as mature and as large as Jenkins is, we require active contributions from both the maintenance and the contributors. It is important that the maintenance and the contributors invest their time in a plug-in that is, which is like what we can say, useful to others, which is not obsolete. So plug-in health care project actually collects data about different plugins and rates them according to their quality. The higher quality probe film have a higher score and obsolete to more of a dips. Plug-in will have a lower score. So why did I chose this project? Apart from the reason that this project was one of the accepted Jenkins GSOC project. I also noticed that there are many probes existing in the project. They do give inside full data, but they do not cover all the criteria. There are many criteria that I could cover. So that is what I proposed in my GSOC proposal. That is why I picked this project. A little bit about me. I am a senior body engineer and I have around 4.5 years of experience. I got promoted three months ago. So I'm also responsible for around three people in my team recently. So apart from learning coding, I'm also learning about mentoring people from my mentors as well. This project is really a great fit for me because I was not really interested in learning a new library. You can send me anything, a new library or something new to implement. But I was much more interested in digging deeper into what I already know. And this project gives me just that. I'm grateful to the Jenkins community for selecting me. I'm also fortunate to have five active mentors that give me different perspectives and how can I do better in my project. This is the first program I worked on that is Unreleased Production Changes Pro. It happens so that many times we already have different production changes, different code that is already fixed like their bug fixes. They can be new features and security fixes. They are ready, but they are not released actually to the production. And there's no use if something is fixed and not released. It is important in the perspective for the developers to collect feedback and also the users to use and what you can say and update it and live version. So this code actually detects if there are any undelivered bug fixes or it highlights that this feature is still and there's an update, but it is not delivered yet. And if the features and the bugs are not delivered, that means the probe might have an inactivated and might need an option. So the details are that this probe in the code actually does is identify set okay this is a production code that has not been delivered yet. And we identify it and give that information in the probe in the list like deliver a list of files that are not released yet. And a good thing that I can share about this probe at this is my first piece of proof that spent life into production. The challenges that I faced is really interesting here because I find this probe a little difficult to tackle for two reasons because I did not have a really good knowledge of hierarchy and also the shake it API was new. I think about the combination I think made it a few difficult for me to tackle. But thanks to my mentors, I was able to overcome it successfully. I also learned about writing unique test cases. And it's a trivial data about learning intelligence shortcuts but I mentioned it because it really helped me in the long run when I was working on other other groups. One part is I had a bad programming session with the mentors. Now I did not know how fun it was for the mentors, but it was really fun for me because I don't really have someone telling me that you can do this better. Or you should write this when you show it to me with this shortcut and then I'll type it exactly. But that's what I learned with mentors. So yeah, that was interesting to me. So this group is exciting to me because this is a community requested when I was reading the details. I saw that the Jenkins in protein usually gets a request that that from a pregnant, you know, that this build is failing, and they say that this third party was so third party repository was it. So Jenkins in protein has to do it manually again. So with this book, they can add the build. Add the repositories in the build at the first time itself. Also, this maven is maven collect gathers dependencies from different repository, and it is important that the repositories are reliable and secure. They also have a default Jenkins repository, but there's not mean that always all the dependencies will be collected from a same repository. So it isn't so this probe actually gives the user an idea that it is other party that is that I used because the plugins might make future build they may cause the assets in our security issue so it is usually great to be aware about it. So one of the biggest challenges that I faced was the identifying all the different parent and child relationships, along with the scenarios which is a common challenge which I usually face because I'm not really aware of I think this is. So this book is actually actually complete, I would say around 60% the reason is we thought that okay this is almost done, and during the review and test cases writing process we found that there are a lot of assumptions you made about maven project hierarchy. And there were a lot of edge cases that we had left. So until we get a good idea about the edge cases, we are the edge cases, what we have to work on and we tackle them. So we decided to put this probe on board. Though we have a solution in mind is to write an effective form that effective file actually, which will be a whole service that will get effective form using the different maven hierarchies. In this I learned in this program I learned writing parameterized test cases. The important thing was any form structure in items I went through the original documentation and maybe. Okay, so as we, this is the third book that I was working on it is GitHub security scan. So GitHub world is sorry digital world is really vulnerable to attacks. And that is why our Jenkins security team has configured GitHub actions, they and which scans the source codes as soon as it is. It is what you committed into the continuous integration thing. And it is also considered a good practice by the community Jenkins community that we take care of security and we scan things as in when we are progressing. So this is what this scan probe encourages it to make sure that the security scan is configured in GitHub workflow directory. It emphasizes on security, and it makes sure that the security part is configured correctly. Okay, and this thing in this probe I had challenges, but most of the challenges were refactoring the classes. There was court application in continuous delivery group and security scan workbook. So I had to write a refactor a class that was application, and I had to take, take an existing contribution from a particular. This blog is under review, and I learned in this group about the good, good branch spacing that you need test cases. And how to benefit from different classes. Okay, I'm excited to announce you have, you have two minutes to wrap up. Okay, I'm excited to announce that. Okay, no problem. I'm excited to announce that in the second half of the cheese sock. I'm going to work on a renovate a board that would detect if a plugin is using the end of it. This is similar to using a dependent board. I will also work on a program that will count the number of open tickets in the plugin, and then I will also work on that will say that okay, the plugin form is not updated to the latest Jenkins program and many more things. I'm also going to write a scoreings. I'm also going to design the scoring system for the groups that have complicated which I have not started yet. And I will also write blogs to document each of the books that I have done. Next, what I want to learn is, I want to learn designing classes and the birds using the concept from scratch, which I usually won't get a chance to do at all. And I also want to write integration test cases. So, do you have any questions now. That was nicely on time in Jakruti congratulations so open for questions. So Bruno do we have questions in the q&a channel. I can't see any questions for some being or even something written in the chat. Okay, we'll wait for a little time. Are you okay john mark if the rest of us ask questions. You're most welcome. Okay, so Jakruti as a new as a new contributor where the things that you found were barriers to you things that Oh I wish I'd known that or I wish that other thing had happened differently. I'm open interested in finding ways we can reduce barriers to new contributors. What do you mean in working the project or Yes, so in interacting with Jenkins development and doing doing work in a an area that was probably not your your immediate Oh I'm super strong in this skill already something it was new to you. Okay, so let me tackle this. See when I. When I started I thought that she saw could be like see I would be able to do it. It might be really easy for me. But as soon as I worked on my first group, let me tell you it wasn't easy at all. Like I said about jagged and get hierarchy. I think, I think as a new contributor whoever is contributing to the project, they should have a lot of background information about Jenkins, and about different functionalities that we use. So I think that might make their journey easier. And since I did not know everything. Yeah, so I took some time in learning things that way. Thank you. Thanks very much. So, so more information about Jenkins and how to use it more information about sounds like Jake yet and get were important to you and certainly they're important to me so that that fits. Good. Thank you. Thank you. Thank you. The mic open for questions from the Q&A chat or direct questions Bruno no questions on the chat. No questions yet. No. Okay, then we'll. Oh, I see a question raised hands. I think from a participant. So, this is a special zoom meeting where attendees cannot speak. So you're invited to type your questions in the Q&A panel. So we'll have two minutes. We're also actively managing the monitoring the chat panel. So Q&A is the better choice and certainly the best choice to ask the question. Yeah. Okay, I don't see where we're going to see if we can catch these questions in a way or the other. And the answer to them later either in this session or in another session. We have a question if we still have some time. Okay. I'll give you a minute and a half. Yep. I'm studying a DevOps tools and I want to contribute but I don't know the way. Oh, it's general question, not to Jack Ruthie. I guess Mark, would you like to answer? Sure, there's a web a web page Jenkins.io slash participate that offers 10 or 15 different alternatives of ways you could contribute. There's also the Gitter Chat channel for newcomer contributors if you want to explore very specific ways, maybe you're interested in Java, maybe JavaScript, maybe like Jagruti's project you're interested in something that will help the infrastructure or help users assess things. Maybe, maybe like other projects you're interested in documentation, all of them wide open and that participate page is exactly the place to go. Okay. Thanks a lot. Sorry. Thank you for your answer and for the tips, Mark, but we need to move on. Otherwise we run out of time. Yeah. Jack Ruthie thank you very much for your presentation. And the answer. Can I ask you to thank you for listening. To cut your sharing and give it to so that Alyssa can take it back. I'm sharing right now John Mark. Okay, got you. I'm just waiting for the slides to loads and the next one to speak. It shows loading. Is that, is that the same for everybody because for me it's showing harshest page is loading, loading, loading. Same for me. It shows a Google Doc document. Just go ahead and share again. Yeah, there we go. Okay, thank you. Okay. There. So, next one. Are you there. Okay, good. The floor is yours then. Good morning. Good afternoon and good evening, wherever you are. This is the good lab plugin modernization project under Google summer of code 2023. I am harsh but I've seen, and my mentors are Mark, Basil, Christian and frame meta. Next slide please. So a bit more about me. I am harsh, and I'm an open source into the app from India, my interests lie in different computer science fields like DevOps and blockchain and some other non technical fields like economics philosophy and many more interesting stuff. Unfortunately, I'm an undergrad at Indian Institute of Technology Kanpur, and I started contributing to Jenkins from February, and I got hooked since then. You can check me out. Next slide please. So let me give you a bit of a technical brief about the project. So, get lab is a fast growing modern depth tech ops platform that has evolved quite a lot in past year, but unfortunately Jenkins couldn't keep up with it. So here comes a good lab plugin modernization project for helping the community. So what is the good lab plugin about the good lab plugin enables seamless interaction between Jenkins and good lab. So what is this project about the project is about replacing the usage of very, very old rest easy library with good lab for J API via get lab API plugin in the Jenkins library. Once this project required this project will greatly reduce the maintenance issues that we can have in the future will make the plugin more lightweight as get lab for J requires much less manual dependencies will improve the consistency with other Jenkins plugins and also most importantly improve the documentation. Now how was this going to be happening. Let's see this is what the project and the presentation aims to convey. So next slide please. What has happened in the coding phase one. So I was just a two month old programmer, when I started contributing to Jenkins and it has been a great experience. So I learned quite a lot in this phase, like get GitHub and most importantly get lab. I did extensive debugging even inside some Docker containers. So to improve my knowledge on Java, I learned a lot about Java building spot works and other Java tooling. I also learned about functional testing using J unit Mockito and other Docker based testing. But what has happened what did you do after learning all these things. So I completed a migration from rest easy to get lucky API via the good lab API plugin, and we as a mentoring team have successfully tested the migrated plugin interactively. But what has changed, if the plugin was so old something must have changed right so migration should be like a magic but like ideally it should be but it's not. So over the years get lab has evolved a lot and does during the migration we found out that the plugin was supporting the version three which get lab does not support currently and so I am using this presentation as a medium to the users that are using the version three of the get lab API should be switching to get lab version get lab API version for as soon as possible. And for more information, you can also refer to the references that we'll be having later the minimum get lab version for this plugin, the updated plugin will be 14.0 and the minimum Jenkins version will be the 2.387.3. Next slide please. Let's see if it works or not live. Let me share my screen. So is this visible. Yes, it is. Okay. Get lab.com production server here, and I'll be using a Jenkins Docker instance. So, I'll be making a change, like I'll be committing a change. And let's see if the freestyle job gets triggered or not. I have already set up the configuration and the compatibility between my development release of the get lab plugin and my Jenkins. And let's see if the get lab sample job is working or not. You can see it has started its work. The console output is not going on. It will take a bit of a time because I've created a lot of things. And it's going to check out. Yep, it's a connection success. So everything worked as we wanted it to be. Let's see the changes and here is the commit that I made just for this thing. So let's go back to the slides. So yeah, journey ahead excited about it. It seems to be working. So the following things that I'll be doing the second coding phase, I'll be adapting the webhooks to the get lab project API events. This is a work in progress currently. I'll also be migrating the proxy settings and adapting the tests. I am currently adapting the test. It's also a work in progress. Of course, I'll be improving the documentation. It's the most important thing for me. And we, I and my mentoring team are going to do extensive testing so that the community does not face any problems and ideally the migration should feel like magic right. So next slide please. So for instance, if you are more curious about the project, you can learn more about the project to the project page, you can join us for the project discussions the get a channel, you can also see a refer to the project notes and maybe you can join us some project meetings also from this link. And if you want to file a request or if you have an issue with the things which were which we are doing right now, you also have to get a repository thing for doing that. Next slide please. Thank you, especially to my lovely mentors supportive community and for your patients. Next slide please. So if you have any questions you're free to ask now. That was great presentation harsh and especially that you finished on time so that's great stuff congratulations here. Are there any questions, don't hesitate if you have questions to write them either in your Q amp a or the chat. If people in the panel will also want to ask questions, they can go ahead. So harsh you noted that it was a you were a very, very new programmer. What sorts of things helped you get started what were things where you might suggest as others start their development journey. What sorts of things did you find helpful what things did you find hindering. So, when we learn programming, we are mostly making our projects which which is very comfortable like we learn some technology and make a project on its own, but when we start contributing to open source. It's a completely new arena when we are stepping in, and you need a lot of help from people. So don't shy away asking help. Also, start having a habit of reading documentation manually it has helped me quite a lot improve on your googling skills that that's underrated but it helps a lot and research is a part of software engineering according to my experience, like a very small experience that I have. And it just goes fine be optimistic and be hardworking perseverance is the key and persistence is very important. But but you asked some questions didn't weren't there awkward times when you felt like you were asking a question that someone might have thought was obvious or how do you how do you overcome your concern. Oh but I'll look, I might feel silly or I might feel badly that I asked a question that was so obvious to everyone else how do you deal with that. It is research like whenever you ask a question, you should have researched quite a lot of about it, either it is a difficult question for someone who you were even asking or the person is quite experienced to know that it is obvious. If you're asking someone a question and the person who is answering feels it's obvious that means you're asking the question from a right guy. And if you're able to ask the question from a very experienced person that means you have researched quite a lot, because if you ask some random question like how to do this. Nobody will be able to help you you must be having detailed questions so that people could help you. So don't shy away be shameless. Great attitude. Very wise. Thank you. And I liked the Google is your friend art so sharpen your Google skill Google or whatever other search engine. Other questions Bruno, something on the channel. No, I can't see anything. Don't be shy. Do like harsh as questions. Proposed that we. There's a question mark. I'm sorry. I'm sorry. 30 seconds for a second for a question. Aaron Conaway asks, sorry for your name. What went wrong, harsh. And what was the most frustrating part. Personally the most frustrating part were the tests because they were so damn old, like you, I first tried to adapt them and I came to a conclusion that they're very old. Then I thought of improving them by making some changes but they still were told. So I had. So we are currently trying to find some solutions for making for making it more modern using the test containers that we are discussing it right now. As the test was so old, it was actually kind of a liability because we couldn't use it for testing whether the production code is correct or not. So yeah, that's that's one frustration that I have with the project. Okay, that was a good. Aaron says a lesson in technical depth. Yeah. No, I can see any other question just a comment from Aaron lesson in technical depth. Yeah. Thank you Aaron. Okay. Thank you so much for this interesting question we're going to move on to the next contributor. So Vendit you're on a roll and the floor is yours. Thank you John Mark. Hi everyone good morning good evening good afternoon, wherever you are I hope you're all are doing well. So we are discussing about the project of discussing about my project, which is building Jenkins.io with alternative tools and the mentors, the people who really helped me were our Mark wait Christian human going and Rajiv Singh. Next slide please. Before moving on, I think it would be nice if you guys know something about me. Yeah, awesome. So my name is Vendit and I'm a computer science undergraduate from India. My journey with Jenkins started in July 2022 where I began contributing to Jenkins and as a beginner, you always take the hardest tasks to do and you fail at you fail at it quite gloriously. So I did that and I learned Keith I learned that I still have to learn more. So I, I stuck around and I contributed contributed some more. So, this was how my journey with Jenkins started my interests are developed development and building things particularly I love open source because it will take over proprietary software in the near future and we all love open source for that. So connect with me. Those are my, those are where you can DM send me a hi. I love, love talking to strangers. Next slide please. Before we go on I would like to put, I would like to put light on the things will be discussing today. We'll start with the project description, the things I did, and what was planned and what changed because when you are making a project things change while while making it and then we'll get on the demo and I'll take your questions after that. Next slide please. Yeah, so my project is my project is building Jenkins I was alternative tools as the name suggests. The currently hosted Jenkins Jenkins.io site is made with Austin, which is under maintained heavily under maintained because the last, last commit it had was two years back. So that's why we are migrating to new tools into ran Gatsby, because maintaining because using an under maintained so software can be quite damaging to the documentation and to the users of Jenkins. So why are we using and Torah and Gatsby for the main the main, the main goal was implementing versioning in the documentation and since Austin was taking its last breaths, you can say, so we, it was the correct time to move to which provides wasn't versioning by default out of the box, due to which we'll be able to provide document version documentations to the user of Jenkins. Now, since Jenkins.io hosts many type of documentations user documentation developer documentation will currently only version the documentation user documentation and and solutions and tutorials, because developer documentation remains the same throughout the years. And get we are using Gatsby for the rest of the site expect documentation, because Gatsby is fast and Gatsby secure and who does not like being passed when you're building a site. Next slide please. So the things I have done till now I have completed the user documentation, developer documentation tutorials and the guides. The solution pages still under progress, and I'm currently working on it since it hasn't it has a different layout than all the other pages. So that it's that's what I'm still working on. Next slide please. Yeah, what was planned, when we when we started working on the project. It was planned that we will generate the entire site with Endora expect the YML files and the blog section will be generated by Gatsby. But since we since we are in we are we are in open source and community feedback is really important for us. So we asked the community what do they think about it. So what they said will be next slide. Next slide please. Yeah, so you can find the discussion on the what the community said, but now the community what the community suggested and what we are going with I will be. Endora should only be used for the versioning part and only documentation documentation should be built with it and Gatsby and Strapi CMS will be used for the rest of the site because but because Entity of the Jenkins.io is documentation so Gatsby still has to do some less work but yeah we'll be using Gatsby for the entire site now and also the YML files will still be built with Gatsby. Next slide please. Yeah, the issues we face because when you're building things we face issues. Forstuk uses inter-page linking. Inter-page linking is completely different from how Entora uses it. So I'm still working on removing the how forstuk does that and implementing how Entora does it. So that is a great issue that I'm facing currently and still working on it. The data table API is used on some pages on Jenkins.io to show some information about the repositories so that was not working it was due to some jQuery issue. This turn helped me with it a lot. So thanks Chris and extension index space has a search functionality that is still in the to-do list because I'm currently in the process to be able to figure it out. And after that in the tutorial sections there were a lot of pages that were just redirecting to the same pages in that directory so we removed them because they were not redirecting and Entora does not provide anything related to redirecting. Next slide please. Yeah, so now going on with the demo I'll share my screen. So currently we are currently we are hosting the site on a GitHub workflow on GitHub pages. So this is this is the site that I have made till now it contains it contains developer documentation, plugin tutorials and the guides and the reference documentation. You can see here we have the user documentation. It is version and as you can see as you can see here I did this page there will be there will be a drop down in this in this site but since we are only since we only have the latest documentation now so I can't show it. I can't show it now, but since after after the projects completes will be able to see documentation versions of documentation that we can switch. And we are still using we are still using the, we're still using the header and footer from the old Jenkins dot IO because these are used across all the sites. From here we can we can see that we have documentation which is a non version. So it is just showing default because it is non version that Jenkins to do we have Jenkins tutorials which are version as I can as I said, when we will have more more versions of the documentation will be able to see a drop down from where we can change the documentation and I'm still working on the solutions page it currently looks like this, but it's still end up it's still in the progress so I don't think so it's really great to show things that are not complete. I have changed the UI I improved the UI and UX with with this with having continuous discussion with my mentors to make the Jenkins dot IO site more user friendly and people can find the documentation easily. So yeah that was all for the demo. Let's get back to the slides. Yeah, the future plans next slide is the future plans of future plans are complete the rest of the work in the documentation site fix interpay linking solutions page. And after that the solutions page layout is entirely different from all the other documentation pages. So that is something I'll be doing. And after that I'll start working on the blogs and the rest of the site pages like security advisories change logs and download page. Next slide please. I'm open for questions throw them at me. Thank you very much for that. That great presentation when the it looks very very interesting and promising. Bruno, are there any questions. Not yet. Not yet. Any questions on the panel. Creating a creating a replacement for a thing that's existed for many years, I would think is incredibly difficult because of all the things that are happening inside it. The Jenkins that I oh site has lots of things going on. What have you done to discover all the things that are being generated there and how are you, how are you learning what's happening with them or if you just narrowed your focus and said no we're just going to focus on a subset. I learned about Jenkins.io was when I was contributing last year. I, I looked around a lot in the repository structure, and that's how I know some things. I already, I already had some knowledge about how Jenkins.io works. Most of the sections I knew most of the largest actions how does the how does them work. And that that that really helped me in migrating migrating the entirety of the site that is really helping me migrating the entirety of the site. Because when, when, when I contributed I, I solved a lot of issues related to documentation how things were building some desk issues so that was how I thought the knowledge and that that is I'm using while building the project. I just would like to add here that the contribution that Vandy did and nearly all contributors in this session made the last part of last year were important preparation for what I call building the Jenkins muscle. So to know and to situate where things are in how to contribute. This helps you to make a powerful proposal and as a chance. Sorry, I have a lot of noise here around me. I apologize if it comes through. No questions yet if that was your next questions or Mark. So were there were there complications that you found in preparing yourself for Google Summer of Code or in preparing your proposal. Are there things that you'd like to share with with others about. Hey, this is I learned this be sure you don't forget that. Yeah, when, when I made my first proposal because I made to, and the first project was withdrawn, but, but since I sent that project was really interesting and I researched about it a lot. But because but after that dropped I was, I was bit down but I knew that I had to, I had to do this because I, because when I was contributing that at that time I found out about the saw. And it was like, since I have contributed and I have the knowledge I can make up a new proposal, and I did so when you are when you are when you are like learning when you're aiming for GSOC, I would say contribute as much as you can. When as her shit as her shit, you should give you should ask detailed questions. Also put the research you did in the questions. And those are the things that really help me and always always know that anything can go wrong but don't don't get depressed when things go wrong. You can just if you have contributed you have the knowledge you can do it again. Thank you for these insights. Yeah, Bruno. If you can't tell me if there are any questions. No, no questions remark. And I think you wanted to add a few things to say to conclude. Yeah. And while concluding I will say if you are interested in the project, you can, you can come to the Gitter channel that's where we talk regularly about the project, you can find the meeting notes. That's where we track everything on a weekly basis and the Gitter repositories that we are using to migrate Jenkins docs and Jenkins UI project, and the project plan can be found on the GitHub wiki of Jenkins docs. Next slide please. So thank you for being a great audience. Thank you to you and it's so we'll move on now to the next presentation. Sorry, just a slight interruption, Alisa, where will we be able to find the slide afterwards because I saw that some country users were sharing some links in their presentation but the attendees can't click on them yet. Yeah, so I will share the slides in the meetup, the meet on the meetup page under the comment section. So that's where I put the links to the recording as well as the link to the slide. Thank you. Okay, thank you very good question for the logistics of this presentation still doing the timekeeping over here. Ashutosh is now the last in the row and was very, very patient and probably very nervous, waiting for his turn. Ashutosh, the floor is yours now. I'm audible. Yes. Okay. Okay, hello everyone. I'm Ashutosh. My project is Docker based Jenkins kickstart examples. Next slide please. Let's see what's the problem this project aims to solve. Next slide please. Let's imagine you have a friend who wants to see what Jenkins is about and try it out. He's curious about Jenkins and wants to try it out. You tell them that Docker is the best way to try Jenkins locally and lead them to the Docker documentation for installing Jenkins. Let's see how their first experience with Jenkins is going to look like. First in the Docker with the documentation, they'll have to create a network with this Docker command. Then they'll have to create a Docker in Docker container with this scary looking Docker Docker command with a lot of arguments and Jenkins is not even started yet. Next slide please. Then they'll have to build a custom Docker image with the Docker file with this command. Then they'll have to run that custom image with this scary looking command with this many arguments. And after everything is done, the setup is running the setup is still not perfect because the setup runs the job on the controller itself, which is the security risk. And the Docker and Docker comes with its own security risks. Another problem is this setup is have a lot of intimidating steps for beginner user and not user is not user friendly. Another problem is that right now on Jenkins.io we have tutorials for users to get familiar with Jenkins that uses the same setup with this Docker commands. Next slide please. Let's see how are we solving these issues. Next slide please. So for the intimidating steps part, we are using Docker Compose to hide all the complexities of the Docker commands. And we are using scripts to automate the running of the Jenkins containers. We have created two scripts Jenkins init.sh and Jenkins tier down.sh. After cloning the repository files, the user only needs to run Jenkins init.sh script and every step for starting the containers will be automatic. And after the tutorial has been completed and the work with Jenkins is completed, the user can use the tier down script to clear everything that the init command started. Next slide please. So this solves the first issue, the second issue of security risk of running jobs on the controller. For this we are using separate containers for controlling agents. We are using multi-container setup with Docker Compose. And we are using another script Jenkins.sh that creates and updates the SSH keys for connecting the container to agent. Docker Compose files are configured with new SSH keys every time the init script is ran. Next slide please. What about the other tutorials? As I mentioned earlier, we are using the same Docker commands in the tutorials that are aimed towards beginners to learn about Jenkins. The target audience of these tutorials are beginners who are here to learn about Jenkins and not about how difficult Docker is. So let's see how they will perform a tutorial after this project. For example, let's say build a Java app with Maven tutorial. After this project, they will only need to clone the repo and use the previous init script with an argument Maven. Next slide please. And that's it. Their whole setup is running with the containers are running with custom Jenkins agent image made for Maven tutorial. And Jenkins can be accessed on localhost 8080. Next slide please. And yes, everything works with Gitport with just a click. Next slide please. Okay, let's see if everything I've talked about actually works. Let me share my screen. Can you guys see me? Yeah, we can see your screen. Okay. So this is our this is the repository that we are working on. You can check it out. This is the Gitport button. Let's see it works. While the Gitport workspace is building, let me show you the original documentation that is right now present. So this is the tutorial. And these are the steps that user needs to do just for running Docker with Jenkins for Docker. Okay, so this is where the main tutorial starts from. And all the steps are just starting Jenkins for Docker. Let's say Gitport is running. Okay, Gitport is running. Let's use the script with Maven argument right now. It's building the Docker image because it uses custom Docker images. Let me walk you through the tutorial. This tutorial, first step of the tutorial is to focus focus repository. This repository for the tutorial. I have already forked the repository and because of the time constraints. And next step of the project, the tutorial is to create a custom Jenkins files and commit it to the local local repo that is cloned cloned from the official and push the Jenkins file to it. The tutorial have four steps separately commits the four stages of the Jenkins files. I have already committed all the four steps because of the time constraint and we see if it works or not. Okay, the Gitport is ready. Let's see our containers that are running. Okay, our Jenkins is ready. Let's log in with the default credentials. As you can see the agent is connected and we are also at the default job in the default job. Let's run the tutorial. This is the first part of the tutorial. Okay, so here you see that Git and here I am using my own for repo and I've already pushed Jenkins file to it. So it should be ready to build now. Okay, it's building as you can see it's running on the agent. And we have also included the pipeline graph view plugin. Since the blue ocean plugin is being deprecated, we are using this plugin. As you can see it's building third step, fourth step, fourth stage, and fourth stage is completed. As you can see all the stages are completed. Let's get back to the slides. Can we have the slides? Okay, so what I've learned during the first half of the GSOC. So I've learned a lot of things. First is get and get best practices, how to resolve merge conflicts. I'm not perfect at it yet, but I'm learning a lot about the Jenkins file system, writing down Docker compose files, writing shell scripts, writing Docker files, how SSH works, how Gitpod works, and how to write technical documentation a lot more. Next slide please. Okay, so what's next for this project, what we'll be doing in the second half of the GSOC. Firstly, we'll be adding more tutorials like Maven and integrating them in its script. Secondly, right now, since we are using shell script, it doesn't support Windows without WSL, which we have some ideas to work on, which we will support Windows in future. And the other big part of the project is testing of these files, Docker compose files and scripts with GitHub actions and eventually with CI.http. Last part of the project will be documentation, developing concise and easy to understand documentation for new and updated tutorials. Next, okay. If you guys have any questions. Anyone in the panel. Thank you for your presentation Ashutosh. Very good. So Ashutosh what was your previous experience with Docker. Had you already used Docker compose before you began working with the Jenkins project. And how did you learn Docker and Docker compose. I actually learned Docker and Docker compose while preparing for the proposal. I was early. I was early for preparing for the GSOC. I was hanging hanging around here for about three months, I think. And the Jenkins community helped me a lot. I was already interested in Docker Docker project. So, a lot of, a lot of mentors help me with what should I do how should I learn things. It's better to start early because community will help you a lot. Thank you. Are there other questions Bruno something on on the wire. I can't see any full time being while we're waiting for potential questions for Ashutosh I would like to congratulate all four contributors for the work done up to now. And also for these presentation not easy to do but I think the goals were, were achieved and good, very good presentations. I'd also like to thank all the mentors that put a lot of time together with the mentors to reach that state. I wish them the same enthusiasm and success were completing Bruno I see a little. Yeah it's not a question. It's a comment from Alexander Brandes. Hello. Not my fault. He'd like to thank all presenters sharing their GSOC progress and stories. He says you really make a difference to Jenkins and the community. Thank you Alex. I would like to thank everyone, the Jenkins community and especially the mentors who spent so much of their time and effort with me and helped me learn so much. And Aaron says applause to everyone great job thanks a lot Aaron. Yeah I think up to now we have a great 2023 edition of GSOC. I think this concludes nearly on time. The four midterm presentation of the four GSOC projects we have this year. Yes, indeed. Congratulations to all of our four contributors. Well done good job. There's more to come so but there's you know we're still working on progress with GSOC so if anybody's interested in next year's GSOC we are always open and welcoming to new mentors so we're always looking for more mentors to help us out in the project. The GSOC website is listed there. We do host a weekly office hours. So meeting notes and recordings are also listed on the link there blogs and communications via our discourse and get our channel is also listed on this link as well. But we're hoping that new mentors and more mentors will join us next year. And for some upcoming Jenkins events where you can you know if you're local, and you're interested in either meeting Mark or anyone or some of us, just check out the DevOps World tour. That's going to be starting in September that's going to start in, I believe it's in New York City. There's going to be three locations in the US, one location in Singapore, and one location in London. There will be a session on Jenkins at each of those locations. And October fast John Mark, do you want to add this is want to give you a comment since you're going to be driving this program. Yes. You're on mute. Well, no, no, no need should work now. Yes, October fast is an activity where we encourage people with minimal experience in open source and guide them to learn how to contribute to open source project and work together. We're learning technology so it means mostly remote, the good old times of getting together in one room are a little bit by gone, but October fast will happen as the name implies in October, and you'll hear more about that and I will lead the effort there and encourage people to participate. Good publicity for G soc October fast is a very good school to start learning and to get the experience what I call the Jenkins muscle to get used how it works to be able to have a strong and powerful proposal and maybe have a chance to be selected for next year's G soc season. Back to you Alyssa. Thank you Mark. Okay, so this concludes our session for today. Thank you everybody for joining. As I mentioned earlier, we will provide the links to the deck, as well as the recording in the media on the media page, as well as in our discourse and get our channels. So if you want to meet us there, chat some more or just take a look back at these recordings you can find in those locations. Thanks everybody. Have a great one before. Bye bye before we close. Yes, before we close I just would like to emphasize, we had to drop projects this year, because we were lacking mentors. So if you're interested to mentor a project for next year's edition. Please reach out. Let's discuss that you can also get prepared for that but for the success of the whole program. We need mentors. So please join us. Sorry for that last publicity at the end of the of the present. It's perfect to you Alyssa. All right. Thanks, Mark. Thanks everybody. Take care. Thank you. Thank you very, very much to everybody. Bye bye.