 Okay, welcome everyone. My name is Nartin D'Angous and this is the summer of code with Jenkins year 2020, the coding phase one demo. I will now share my screen. All right, so welcome everyone. In this difficult year, we have decided to get together and help each other write better code for the Jenkins open source CI CD platform and this year we're participating in summer of code. So the agenda for today is a short introduction to Jenkins in summer of code. We're gonna have demos by our students for the phase coding phase one and we're gonna have questions and answers for at the end of each presentation and at the end of this presentation. So which Google summer of code organization are we? We are the Jenkins project organization. So this is where the Jenkins and the Jenkins X projects are being mentored this year. For the other CI CD projects, please look under the CD foundation website where you're gonna find those other projects. We are the Jenkins one. This is our fourth year in summer of code and this year we have approximately we have had 20 project ideas that were submitted and we accepted seven students. This is a great year for us. We have two to four mentors per project and this is you know one of greatest participation. So we've grown slowly but surely every year. We're hosting Jenkins and Jenkins X summer of code projects this year and if you want to know more about Jenkins and summer of code please visit our website Jenkins.io slash projects slash jsoc. Communication channels to reach out to us. We have a mailing list on the Google groups. We have a Gitter chat under Jenkins CI slash jsoc-sig. SIG stands for Special Interest Group. We have regular office hours on Wednesdays. We are holding them online and via video call whenever needed. There's project specific channels that you can reach if you are interested in one of our specific summer of code projects and the Jenkins X Slack channel is also open for questions and participation. During this presentation we're gonna take questions via the Zoom chat or on the JSOC Gitter chat. So here there's the link. After the presentations you can ask your questions on Gitter or on the mailing list. For participation we have a code of conduct and essentially please be nice to one another and if you want details regarding our code of conduct there is the link for you. The links for these slides here's the short URL down at the bottom. So before we get into the part one demo I just like to remind everyone that we're at the end of the coding phase one where during the we are in the evaluation period. So if there are mentors who have not submitted yet their evaluation just like to remind you that we have approximately one day five hours 48 minutes and 24 seconds left to complete those evaluations. All right before we start would anyone like to add something to the introduction? Nothing specific but I would like to thank all students and mentors who participate in JSOC this year because we've already got a lot of great progress like you're going to see during these demos. We've got a lot of contributions coming from JSOC participants and we appreciate your time and effort dedicated to these projects. Thanks all. Thank you all a guy. Thank you thank you for reminding us that you know everybody's contribution is super welcome and we're very grateful to have all of you participating in this project so thank you. Okay so let's go to our first presentation of this part one of the demos just a reminder we're gonna have part two part two of the demos gonna have three other demos in a couple in an hour and a half two hours from now. Okay so Jenkins X applications and add-ons consolidation by Xuan Liu and Cara is the mentor who's gonna tell us a little bit about this project I believe that's the next slide. Yes Cara. Thank you Martin I would like to speak about his work but I just wanted to say quickly on behalf of Jenkins X thank you to the Jenkins org for having us as part of your JSOC umbrella this year we've had a really good experience and been really well supported and we really appreciate it. So Juan has done amazing work so I will let him now speak about what he has done for us. Hi I'm Zixuan. I present to my Google Summer Code project. My project is a lot of Jenkins X apps and add-ons. Apps and add-ons are both used for extend the Jenkins X. Now we recommend using apps and delete add-ons you can click the foreign links look at my demo. Thank you. Yes. This one has made a great demo for us on on the apps that he's been converting for Jenkins X so you can watch them on the links and he's running a blog post and also you can read more on the project page. So it's been really successful so far and thank you. Martin you are muted. Thank you Cara. Thank you Juan. Yes please visit the demo on YouTube. It has been pre-recorded and you're going to see the details of this project. There's also a blog post that you can visit and it's on the community bonding with Jenkins X website. Next on our list is the... Oh so Cara was that everything? Thank you. Next on our list is the custom Jenkins distribution build service by Sladen and he's I'm gonna give you the... I'm gonna stop sharing and do you have something you want to share on the screen Sladen? Thanks Martin. There you go. Okay just let me know when you can see the screen. Can you see it? Yes. Okay that's amazing. Yeah so yeah so I just wanted to introduce first of all so I'm Sladen and I'm a student in the Jenkins Google Summer of Code for the year 2020 and as my mentors I have Kristin Rick and of course Perichir has been added so apologies Perichir for not actually having a name here but yeah so as well as Oleg as a technical advisor. So yeah so I think I can begin my presentation. So first of all I started with what the project is about. So the initial idea of the project was to make you know to have Jenkins out of the box custom distribution. So whenever you install or you get a Jenkins instance you have to go to the entire process of actually configuring every single instance you know you need to download the plugins you know you need to write the you know select whatever config you need such as the code numbers and so on and so forth and that takes that's be time-consuming it can be take a lot of time and to you know speed up the process or make it easier for a new user to actually use a Jenkins distribution or probably if he has a use case that is very very common in the industry for example you find AWS distributions or you find distributions running on Kubernetes and stuff and which makes it you know which extends to have custom distributions just like on top of the Linux kernel you have Ubuntu you have you have various other flavors just like that. So what we aim to do is to have an out-of-the-box Jenkins distribution with a very simple user interface and actually that's the kind of USP of the entire you know the project it needs to be very very simple to use and you know very easy to interact with so that you're able to configure it in a very very simple way. The third and fourth points of the project what the project is about the community shared configuration so you know Jenkins is all about the community we have a huge community and in order to leverage off the contributions made by the entire community we have community shared configurations that is that if you make a configuration and you want to share it with the world probably we'll have us you know we'll have a feature where you can share your configurations with Jenkins users around the world which makes it very very easy you know because there is a person out there who might have the same configuration as you have and you know why would you want to reinvent the wheel. So yeah that's about it for shared community configurations and easy access around the world. So sometimes you know you have problems with the Jenkins server like pulling in plugins maybe you're running it behind a proxy and so on and so forth. We plan to make this service easily accessible that is one of the deliverables and goals for the project and we hope to achieve that. So yeah that's it for this slide moving on to the next slide. So what's the current problem? Yeah so as I explained in detail in the previous actually this should in the previous description the entire problem is they would have to download Jenkins first select some plugins configure them take a lot of time yeah and so we want to get a perfect Jenkins distribution right out of the box. So it contains all that we need and can save all of that time for it. So that's the problem that we're trying to solve just so that everyone's clear with the problem statement that we're trying to solve. There are links later you know you can visit the project ideas page which describes the project in its native stages but yeah this is the entire Okay what's the project motivation? We work hard so you don't have to that's a completely casual line. So we will be doing all the hard work behind the scenes and we will be leveraging of certain packages that are already present and do all the hard work so that you just have to sit back and just use a sort you know write in simple and plain English whatever you want that needs to happen. So features implemented in phase one so this is a phase one demo and so I'm talking just the features implemented in phase one. So we have four of them currently the package config generation, the watch generation, the ability to configure custom packages and the ability to add plugins to the package. Now this might seem a bit of jogging at the end but what it essentially does is your package configuration just let me see if I can get the point out. Yeah this feels better. So yeah so the package configuration essentially generates the package of configuration. So if you see how the custom package or war package works you need to provide it a configuration file. So what phase one is essentially doing is generating that configuration file for you because without the configuration file you're not going to have a war. So that's stage one. Stage one is generating that configuration file. Stage two is war generation. These two go hand in hand because you need a war to directly just run it out of the box. So this is stage one generating the configuration file and putting that configuration file into the war generator so that we have a war at the end. That's stage two. Yeah so phase one has two complementing features supported to it so you need to have the ability to add plugins to it. So we are providing you with all of the 1700 plugins wherever the box thanks to the update center and you will be have the ability to configure the package once it's ready. So once you have the YML file you will have the ability as an engineer to be able to change certain aspects like if you realize that I want a different version of Jenkins you can do that at the end once the package has been generated. So making the Jenkins initial setup simple. So this is the workflow actually of the entire service and this is the high level workflow. So you select your favorite plugins that you want into your Jenkins distribution. You would be asking the question that hey the setup wizard already installed certain plugins. Yeah we will be providing an option you know to select that you want the setup wizard to run when you run your war but that's a different use case altogether. Customizing the configuration obviously having the chance to you know change the configuration to your whims and fancies you want a Docker container you don't want a Docker container that's up to you and then you relax. So once you relax so generator ready to use Jenkins for you and you just need to download and run. So after you generate the war we will provide you with the option to download it and you can just go ahead and run it. So that's the entire workflow. It's an high level workflow so that you understand in the coming phases I will be keeping the slide always so that you can you know the overall work for the project is. So that's about it for that. Yeah there's more actually. So after you download the plugins you can share it in the community that's the most important part of Jenkins community. So you will have the ability to share those configurations with the world. It might be an AWS configuration a Kubernetes configuration you know basically whatever you have it right out of the box. So it is an example here. I'm not going to be going it outside links for now because I just want to stick to the slide deck. But there are examples such as the Jenkins formula speech that Rick has very well developed for us. So you know that can be used for Jenkins distribution. It gives you an example of what the entire project looks like. But yeah that's that's about it for all of the features that we plan to have for this project. Okay it's time for some demo. Let me just exit my screen and yeah cool. I don't know if I can go into full screen. Yeah no the full screen doesn't show back. This looks better. Just give me a second maybe I can. Oh yeah that's better. So yeah so as you can see this is the user interface for the plugin for the distribution. We have all of the things that we want to have. So as you can see you can scroll to pages. This might seem familiar to the to the plugins page of that of Jenkins where you can search for all of the plugins. So you can scroll around to 1007 plugins and I'm not going to scroll all the way to the end but you can if you want to. And that would give you the list of all of the 1700 plugins into our collection. So if you want to search for any plugins that's possible. So you might search for warnings plugin or maybe the GitLab multi branch source plugin. So yeah that all is supported. So neat and fancy features. So what I'm going to do here is I'm going to follow a pretty simple procedure. I'm going to add a list of four plugins right on the screen. I'm not going to search for any one especially. So what what versions are listed here are the latest versions. We haven't included the ability to reversion them because of certain compatibility changes. So these are just the latest versions. We might have the ability to configure it later. So as you can see I'm going to just add the first four on the screen. So the GitHub autostatus, the CCM, the trigger and the Windows Azure. One, two, three and four. And the next step after you've selected your plugins, you can submit your plugins. So I know you there's not much user feedback on the screen for, you know, saying that it's added to the configuration, but that there are some features in that. You just add the four plugins and you hit submit plugin. Now, once you hit submit plans, you you have the ability to customize your wall package details. So essentially, these are the details for your Jenkins wall. So it might be your title. So for now, I'm just putting Jenkins or latest whatever version. So for now, you can choose whatever version you want. There isn't any restriction. So you can enter your artifact ID for the package. So all of these fees that are being provided here are pretty much so you can get an example as well. And the description obviously of the wall. So this is your demo purposes. You also have the option to add JCAS. If you don't want to use JCAS, but yeah, that's if you have a JCAS point into your Jenkins wall, if you want to insert it, you do have the ability to include it. If you don't, you just omit the Docker build. So yeah, Jenkins experiment, you can click Docker builds. This is a build setting. So if you want to configure it, you have the freedom to configure it the way you want to. You can choose a Docker base, you can choose a Docker build, you know, you have all sorts of options here. And once you generate package, it is going to go ahead and generate and this might take a minute because it needs to pull in all of the plugins and stuff, all of the data. So once you generate plugin package configuration, there's going to be a generation of plugins. So while this package generate, I'm going to take you, I'm not going to, you know, have a staring at a screen for that for a minute or so 45 seconds to be precise. I'll be taking you to the way you can, you know, where this repository is hosted and stuff. So just coming back to this, you have the Jenkins custom distribution service posted on GitHub, and we've used Spring Boot and React as a combination of, you know, services so that to make this project successful. So React is used for the front end and Spring Boot is for the back end. Oh, that too shorter than expected. So I'm going to be screening out. Yeah. So as you can see here, this is the package of config. This is your configuration that goes into generating the watch. So as you can see, I selected the four plugins auto status, the auto status, the CCM, the trigger and the Azure storage with their version number. So you have all of your plugins that you selected the more the plugins are made. I remember, so you can have your configuration as code as well. In your directory, obviously you can change this directory path. Now, one good feature about this is, yeah, just before I move to that, you have the build settings. You have the bundles and stuff. I entered 2.107.3. So that's there as well. And these are default properties. So we were debating on whether to include them as defaults. But for now, we've just selected to use them as default. And this serves as an editor as well. So if you realize that, hey, I made a mistake in the versioning, and I want to change this version, I can, you know, go with, you know, save. So this doesn't look like an editor at first, but yeah, it is an editor. So that's pretty cool. And you have the details of your package at the right. So if you want to just a high level overview, what the description is, what the title is, you can clearly see it right here. Okay, apart from this, what another cool thing that you can do is if you want to use this in conjunction with your custom wallpackager, you have the option to download this separately. So download custom, I can see if you're and I might just click it. And it might take some time to open. But yeah, that's the element of the demo. But yeah, you can download that text file and you can use it for generating your wallpackage. So as you see, that's just generally opened up as a text file. Apart from that, that's all about it for the demo, the download file option. Now you may wondering, why is that button there? So that button is actually there for it's a phase two delivery. So for the next phase, probably you'll see that button working. That button, the war generation has already been implemented, but you just can't download it from there right now. So that's a phase two, you'll be able to download the file and probably I can show you in the next phase how you can run it out of the box. That's for phase two. So coming back, that's that's about it for the main demo. I'll take you to the remaining slides. Just how you can participate. So as I showed you earlier, this is our GitHub page, please feel free to visit this page and you know, open up any issues that you have with the service. It's pretty simple to just spin it up and run. So we've provided Docker container, a few, a few commands in your app and running. Apart from this, we do have a GitHub channel, or the customer service. So you can, you can have a look here, you can feel free to ping the chat or if you just want to say hi, it's just completely okay. Yeah, and there's a project link as well. So you can find the project links. In the description, these slides will be made publicly. Okay, what's next? That's interesting. So what's next is you saw phase two, we're done with phase one, and it was absolutely amazing. What we plan to do for phase two is focus on improving the user experience. I know I'm not very good at UI. But yeah, that's something that we aim to improve for the next phase. So that is pretty easier to use maybe less of scrolling and stuff implemented the war generation and download. So that's for phase two again, so that you can download the war file and use it right out of the box. And milestone. So I've set up some of the milestones for phase two, so that I could take you through just a just a few just a few of them, not not deep diving into code. That's not what the demo is for. But yeah, if you want to have a look at the milestones, I'm just showing you these are some of them GSOC phase two. We have the ability to download packages, the cashier management, some of the, you know, some of the positive reset up and stuff. Feel free to have a look at these milestones and suggest or, you know, criticize any of the stuff that's there. Apart from that, yeah, that's about it. Just before I hand over the bike, Mike back, I would like to thank my mentors, Christian, Christian, Rick and Parichay, they've been absolutely wonderful. And I've enjoyed working with them a lot. I'm hoping to, you know, work with them for the next two months to make this project even better. So yeah, handing over the mic back. Thanks a lot. Thank you, Sliden. This is a very nice presentation. I would like the I would like to invite the mentors, Christian, Rick and Parichay. Do you have questions or comments? No questions. But I would like to say that Sliden has done a great job. This first, I guess, milestone, you saw like that incredible demo. And I know that he said his UI skills are not that great. But I think it looks amazing. Like, it's really cool to be able to click all the different cards and be able to add plugins. I think he did a great job. And I'm really looking forward to milestone two and seeing what he can accomplish. So congratulations. I think he did a great job. Hi, so I also agree with Christian here. Sliden has been phenomenal. He has been independently maneuvering through the project and independently implementing a lot of things. So it also helping us as a mentor and all the best Sliden for the next phase two and he did a great job. Thank you. Thank you. Anyone else has questions? Yeah, I have a quick question. Yeah, mostly about the front end part. So right now we have at least three places where we have a listing for plugins. One is the plugin site, which is basically written in React as well, with Java not screened but Java as a backend. Then we have plugin manager and set the Jenkins core. And now we have the custom Jenkins distribution build service. I wonder whether there would be opportunities to at least consolidate the recent implementations and have something which would provide a unified user experience regardless of how we use the plugin listing. What do you think about that? Yeah, that sounds really interesting because we have three different places and rightly so actually having a unified place to pick up plugins from our central place, that's really amazing. Yeah, taking into consideration that could be done for the future to have a central listing. But then that would make it in coming back to the service in order to generate the list because for the custom distribution service you would need to have those plugins pulled or something. So it would it would make it difficult to come back. So that's just a concern. Apart from that it's a nice addition. So I think right now the endpoints for getting the plugin list is only serving the entire list of plugins. We could have a paginated query sort of a thing implemented so that we only get a chunk of the plugin list that we want to show in the front end and then likewise when user searches or user go to the next page then based on that further plugin list would be placed. So I mean that's a thing for phase two. Definitely. So that's why I was asking about unified view because, for example, if you go to the plugin site, you can discover that all of the search capabilities are there. Yeah, they're written in React, mostly. So. Okay, so this has been implemented, the paginated query as well. Yes, if you go to the plugin site that supports the for paginated queries, I believe I can double check. But if not, it's well, it's definitely something to consider for that as well. Yeah, definitely. I think neither me or Slaydon explored in that area. So maybe that's a thing that would add to the list and phase two. Yeah, exactly. That's something you could add to the list. Thanks. Anyway, it's really great to see the progress there. Yeah, I can confirm that back end also works. Just need to glue it together with the front end. Great. Any other questions? All right, let's move on. So our next presentation is regarding the world most popular source code management system Git. And this is a presentation on the Git plugin performance improvements by Rishabh. Rishabh, I will let you have the screen. Thank you Martin for the introduction. I'm sharing a screen now. So I'm going to talk about my project, which is the Git plugin performance improvement. My name is Rishabh, as Martin has introduced me, I would first like to thank my mentors before I move on. Mark, Fran, Justin, Parish and Omkar, their constant guidance has helped me a lot during the development of this project during phase one. So about me, I mostly code in Java. I have some interest in machine learning as well. During college, I wrote a research paper on the application of convolutional neural networks, which I got published in a conference. That's it. Now the project, the aim of the project is simple. It's to improve the performance of the Git plugin. Now before we move on to how we are going to do that, we first need to know that the Git plugin essentially provides the Git functionalities with Jenkins. And it does that by providing two implementations internally. The first one is the command line gate, and the second is a pure Java implementation called JGit. So by default, CLI Git is included in the plugin. But if a user wishes to, they can use JGit as an implementation as well. In our infrastructure, in our CLI, we use JGit as the default implementation. So what we want to do, how are we going to improve the performance of Git plugin? The first, there are two stages to the project, and both can work parallely. The first stage is to apply a microbenchmarking framework to study, to gain a comparative analysis between the execution time of the Git operations implemented in both of these implementations. So what we want to do is, is we want to, we want to basically isolate the Git operations, and then ideally find out which implementation is performing better than the other, or particular parameters like the repository size, or the number of branches, or the history, the commit history, and, or maybe the different platforms like Windows, or Mac, or Linux, other distributions. So, so that is the first stage. And the second stage is to use the insights we get from that analysis, and to you, and to encode, and to code those insights inside the plugin. For an example, if we find out that the performance of JGit is affected by the size of the increasing size of the repository, we can add a switch inside the plugin when we see that we have a large size repository, we can switch, we can switch from JGit to Git, and, and basically stop the degradation of performance. So, so what we've done in phase one, what we were supposed to do, and we've done, the first was to integrate the GMH benchmarks inside the Git plan plugin. And I did that, you so it was pretty simple, because in a previous year GSOC project, GMH is basically provided inside. I had to do nothing, not even external dependency. It's provided in the Jenkins unit test harness. So I just have to, I wrote the Git, I wrote to Git operations benchmarks, the first is Git fetch, and the second is Git LS remote. And then the second step is to validate those benchmark results. So how do we do that? The first is that I create some baseline experiments, like using system.nano time or timing those operations. The second is to profile the Jenkins instance with Java flight recorders. And the third is to ask for expert opinion from the mentors I have here, the maintainers of the plugin instance. So these three are the ways I validate the results I get. The second deliverable was to fix an existing performance issue inside the Git plugin, which is called the Git, the issue is that we call Git fetch twice while we're checking out the repository. So we had to fix that. The second was the third was to possibly design a strategy to implement, to strategy to implement the improvements we are going to find out from the benchmarking strategy inside the plugin. So why, why do we want to performance benchmark? I think the reason is that for any Jenkins pipeline, Git plugins can possibly be a performance bottleneck. And why? Because it involves considerable network and I operations, for example, cloning a big large repository. So ideally, we would like to find out, we would like to find out the bottlenecks and then possibly fix them. So for an example, through benchmarking, I found out that for a large size repository like Ruby, Git is going to be 220% faster than Jenkins in performing a fetch operation. That's, I think, big enough motivation to do this project. Okay, so how am I, how am I creating a comparative study between those operations? It's done using the Jmh, which is the Java micro benchmark harness. It's, it's provided within the Jenkins unit. So I don't have to add anything in the, if you've integrated it inside the Git client plugin, we have to plug in the plugin and get client plugin. So the steps we perform to, from writing it to analyzing the results is we code a benchmark, we then run it on the infrastructure, and then we visualize the benchmark. So I'm going to show you all the steps. The first is that I have added a module inside the Git client plugin under the test module. This is where the benchmarks live. For each operation, I create another benchmark. I have some utilities as well to support the benchmarks. Then the second step, which is to run it on the infrastructure, we just have to add another step called run benchmark, which is provided by the previous GSOC project. So it's very convenient to add it to the infrastructure. The third process is to visualize it. So what we've done is right now I've locally added, so there's a plugin called Jmh report visualizer, which what it does is it ingests the benchmark results from the, from the framework and it visualizes those results. So once we, we integrate that plugin inside the Jenkins instance, you, once you build your project and run the benchmark, you have a new tab called Jmh report. You click it and you can see the benchmarks visualized and you can analyze them. So this is how we've, we've, this is our benchmarking strategy for the plugin. Now, git fetch. So with first git fetch, I'd like to show my results and the analysis we have done with it. So with git fetch, let's concentrate on the first graph here, the first graph here. So the first graph I have the x-axis is the repository size. The y-axis is the average time execution, any seconds per operation. So for an increasing size of repository, you can see or get off a jacket that time is going to increase. That's an obvious fact. But one interesting thing, which you might see here is that there is a change in the nature of performance of jacket as the repository size increases. And how is that happening? If you, if you, if you concentrate at this part of the graph, for a repository size less than, let's say 5 MB, JGID is performing better than JET CLI JET. And once we, once we move on from a certain point, then JGID is exponentially the performance of JGID is degraded. And this might look like the graph might look like they're going to converge at some, at some point, but this is, this graph has been taken on a log scale. So then I'm saying the degradation explanation, it is actually it's not going to converge here. And quantitatively, if we see the results for Ruby, I benchmark the git fetch performance, the git fetch operation or both of the, both of the implementations, there is a two minutes, 20 seconds difference between git and JGID when we fetch Ruby. So that's, that's a huge difference. And on the second graph, you can see it's, it's the nature of JGID performance is same. The intersection point, where the nature changes or the infection point, it's, it's a little different from what we've seen in the first graph. But, but the main point to emphasis point is that there is a change. And for large repository, large size repositories, JGID is going to perform, I would say if the performance degraded, and it adds a lot of overhead, if you're using JGID for large size repositories. So insights, the first I've discussed, it's that the execution time is of course going to increase as the repository increases. The second is that there is an infection point on the scale of the repository size, where the nature of the JGID performance changes. Now that the important part is that we can use this in insight to implement a feature, which would avoid JGID when we are using large repositories. And I've shared the quantitative fact. Now benchmarking get LS remote. The experiment was pretty simple. I am my benchmark is interacting with the five repositories here, and how the repositories, the size increases, and the number of references increases as well. These are the number of references, the references, when we see references, there's a branches tags and pull requests, all of those references, some total. So, so what you see here is the exact visualization which we get from the plugin. So let's just concentrate on get support gate, all those five repository, the performance as the size of the repository increases, the get LS remote is going to take more time. And that's I think an obvious fact. But the main question is, when we compare gate and JGID, is there a difference in performance? And there is none according to the benchmarks. It's actually not very much. It's less than a second, less than a half of a second. So even if you see for the for Kubernetes, which is a large size repository, there, there is a difference when we look at get and JGID, but there is a pretty big error in measurement for these calculations. And that is happening because for this benchmark, we're involving network for the get fetch when I don't use I use a local get repository to fetch to to benchmark the fetch operation, but for this operation, we're directly using the internet. Now the second deliverable was fixing redundant fetch issue. So what was the issue? The issue I can show you just one second. Yeah, so the issue is very simple when you're in during the checkout step, the plugin is going to fetch the repository once and again going to do that. So this is the issue, the solution, the solution was that I provided a function which determines if we want to avoid the second patch or not, which are related to references impact of the fix on the get plugin performance. So before the project marks the maintenance of the plug in mark and they were they used to get reports that the redundant fetch is adding considerable performance overhead in their setup. So so that's that's what we're loo what we're basically fixing when we're saying that we're avoiding the second patch. The road ahead for the phase two, what do you want to do? So as you've seen that we've gained some result is where we're seeing that the performance of get fetch implementation is directly correlated to the size of the repository. We would like to create a class called get repository size estimator, which ideally would like to estimate the size of the repository without cloning the repository. And we have discussed some heuristics we are going to use to do that. We don't have a definite way to do it, but we have some heuristics, three heuristics actually to do it. It's still under discussion proof of concept is still to be made. So that's what we want to do. And that is how we're going to move forward with implementing the insight we have gained from the benchmarks. The second thing we want we would like to do is to move out from the analysis area right now was get SM checkout I focus too much on profiling and benchmarking it the operations involved in the SM checkout now I want to go to multi branching multi branch pipeline and organization folders. Third is to validate benchmarks with more confidence that is to when I'm benchmarking get fetch, I should validate that it's bringing the right amount the right size, the repository, the amount of the size of the objects, it's correct so that I don't get results where I don't analyze the results which are the operation is not even working correctly. The last thing is broadening the benchmarking parameters. So we've seen that not only the size of the repository, but the structure that is the number of branches, the commit history and the tags, all of that can also have can have a an impact on the performance and we need to perform a sensitivity analysis on that part as well to gain better insights. So this is it. Any questions? I have one question. So yeah, you benchmarked different git implementations. But I wonder whether you benchmarked the plugins themselves, because we have the client plugin, we have a git plugin, we have a number of other plugins they depend on, for example, for credentials, etc. And I wonder whether the existing benchmarks cover this part of the code base and whether it's considered to be a potential problem for performance. So like right now, our scope of benchmarking is micro benchmarking is that we are focusing on the git operations we have inside the git using the providing by the client plugin. So currently, we're going to focus on testing different operations under different scenarios and possibly find the differences in the implementations. Yes, that is the current scope of the project. I am all like I am interested in the idea because we have some automated tests already that use credentials. So it should be possible for us to at least include credentials in the in the micro benchmarks. So good, good suggestion. Yeah, credentials themselves, they're probably not a concern. Unless you want to track credentials, because then also fingerprint engine gets involved. But for example, even if we take a common git operations, like get to check out a CM steps, there is a lot of additional steps involved, for example, parsing, the commit history, preparing for visualization actions and other things, which can be a significant overhead for performance, or maybe not. But we are still okay. I get it. We will add it to our scope of benchmarking. Okay. Thanks. Because games just the common problem. And usually when you work on performance is better to have some metrics on the top level. Because, well, I believe that it's not a case for git plugin, but sometimes when you start optimizing low level logic, you may realize that it's actually not a concern on a high level, because there are problems with algorithm, etc. in your business logic, which basically cause a lot of a lot of performance depredition. Again, I do not think that it's a case for git plugin. But yeah, that's a nice thing we can do. Okay. Okay. Very interesting. Thank you, Richard. Is there are other people who have questions for Richard? Richard, have you had any thoughts on how to deal with what appeared to be platform differences? On your right hand graph, you showed windows on the left hand Mac OS and they had a very different breakpoint. Are you envisioning that things may may also be specific to platform or no, your heuristics are planning to stay independent of platform? The heuristics will not stay independent of the platforms. There might be differences when we consider windows. But what you see here might not be the actual representation of the point we're talking about there, the nature of jagged changes was quantitatively when I see the results from the benchmarks, what I see is Yeah, sorry, we just lost your audio, Rishabh Martin, I think we may just want to go on with the next the next presenter. Rishabh's done an excellent job here. Okay. All right. Well, thank you very much. And seems like there's networking problem. So let's move on. Thank you, Rishabh. Okay. It seems like I cannot release the screen share. I am trying to do it right now. It's not letting me do it. Do you want to pause the recording, Markey, while we sort out this technical issue? Well, we cannot cut it later. Okay, you have to cut it anyway. Because we're in the middle. Yeah, feels we're stuck. Rishabh, if you hear us, can you please release the sharing? Thank you. Go ahead. All right. All right. Our next presentation today is by KZ. And the topic is the GitHub checks API for Jenkins plugins. All right, KZ, you, you can share your screen. Okay. Thank you, Martin. So can you see my screen? Yes. So hello, everyone. I'm Koji Shun. Today, I'm going to present my Facebook progress on the JSOC project. You have checks API plugin for Jenkins. And I have two great mentors. It's really an team. So first, I want to introduce a little bit about the GitHub checks API. And so basically, it's just a highly customized way to integrate the CI tools like Jenkins, Travis, or Codesc to make reports for PR. So it has some parameters like the status, which is used to indicate the current stage of the CI job, like the Jenkins build. And we have conclusions. And the third one is one of the most, maybe is the biggest reason why we have this plugin here, this annotation. And with annotations, we can make warnings and notices on specific lines of a code. You can see the annotations here. It's just like the comment you made, while you are reviewing other people's PR. The last one is actions. With the actions, you can try to rerun the CI jobs and you can even do the automatic formatting or fixation. So here, this picture is from the official document from GitHub. It shows the status and some other informations. So back to our project. I want to first talk about how Jenkins is currently integrated through the GitHub status API. But the status API is very limited in its function. It can only support the status and the short message. And if you want to see more about this CI job, you have to click this detail link here. And normally it will direct you to the blue ocean page. But we all know that Jenkins can do more than just the status and the short message. And for example, we have the warnings plugin. You can see here we have many warnings from different tools like PMD and CheckStyle. And we can even have this trend charts to help you control your code quality during your development. And also for the code coverage API, I have this GIF here from Jeff's slide. It shows the file filtering feature of the code coverage API. So what we are thinking is maybe we should integrate these functions to GitHub. And so we can make the Jenkins more convenient to the GitHub users. So like for the source code view from the warnings plugin, you can see here, here is a spot block wording here. Maybe we could migrate it to GitHub as a trigger annotations. So for this one, we have developed a general API. We did this because we want to be prepared for the similar concepts in different platforms. Not only GitHub or maybe GitHub or GitHub later. And on the code qualities, we try to keep this API simple. It only collects parameters from users. And we try to keep a consistent style for different parts of this API. And we also keep this API well documented as other parts of Jenkins and make it well annotated to avoid misuse by the developers. And we try hard to keep this method testable and reach more than 90% of code coverage. So we also provide the implementation for our GitHub checks API. And the image here shown is the ones I create through our plugin. If I click the link here, you can see it. So this is the title for this check. And this is the action. We have the support, the actions currently. And we will do that later in the second or third phases. And here is the summary, simple summary. And I post the image here. But later, you can imagine that there is something more useful. Charts like the code coverage charts, the wordings trend, anything that's more useful. And for details, it's just this detailed support smart console is very flexible. And I have also added two annotations. You can even see the annotations while actually reviewing the PR here. So the next part is the demo. For the demo, it's basically simple. Just whatever triggers the Jenkins build here. For now, I just click the build now button. And it will start to build the Jenkins, the job. And then later you see here, wait a second. You see here, the first one demo is Q. And Jenkins Q as well. So it's in progress now. We haven't provided any output for this in progress by the users. The consumers or API can feel free to make any outputs here while the checks is still in progressing. It depends how the users use our API. So when it's done, it's the same as I showed earlier. And here in the file changes are also same. And back to here is another thing is about the details URL. Here I just provide the URL for the I said Jenkins.L, but maybe the users or developers, consumers of our API could provide URL like this build page or other lotion pages. It depends how they use our API. So any questions about our working? Thanks a lot. It's a really great demo and I'm looking forward to see this feature. One question about the project plans. So are you working on the unchecked API or do you consider it also implement the deployment's API which becomes quite popular as well and the beach has similar restrictions? I'm not quite understanding your question. So there is a checks API in GitHub but there is also a deployment's API. And the deployment's API allows to specify for example where the particular quota was deployed as a part of your Jenkins pipeline. So I wonder whether it's... Sorry, sorry, the deployed API is not running our current plan. Our plan for the next phase is to use to let the warnings plugin and the code coverage and plugin to consume our API to publish those warnings. And for the third phase maybe we'll support the pipeline and also for if we want actions and some other our works. Thank you. Thank you, Kisi. Is there questions or comments from from the mentors of the project? No, I don't have any comments. Just want to say thank you. You did already an excellent job and I'm really amazing what you did and I hopefully we have another good phase in the second phase now. Thank you. Thank you, Uli. All right. Any other questions for Kisi? Kisi, have there been any particular problems you've detected that that might be irrelevant to the audience that's listening? It looks brilliant to me. I'm excited to use what you're doing and thrilled. Are the things you've learned in the process that oh hey this was much more difficult than I expected or this was easier? Well I think the biggest challenge is to make my code more like to have a high quality because for example for the non-rural problem I try hard to get out to get rid of it. Use optional some other more standard coding styles and those are challenging and also for and also for like because of our project currently just based on the branch source and plugins. So before they I tried hard to find a way whether we can like use it more general instead of just based on the GitHub branch source plugin. We also think I also thought about whether we can support the GitHub plugin but a problem says that maybe the URL for we cannot resolve the headsharp or URL from the GitHub GitHub plugins or other plugins except the GitHub branch source plugin. So that's a problem I made currently and so Thank you. You mentioned that you support other people to send output to the different checks. Is that something that you would have as a pipeline step that you'd be able to use or Is that something you mean? You mean for the pipeline support? Yeah. I guess well we'll add the pipeline support in the third phase and about in the next phase because we are we're testing the the warnings plugin and customer API in the next phase so for the warnings plugins users they can just but the warning plugin supports the pipeline support support the pipeline so when the users use their plugin and our API is just called by the warnings plugin so. Great thank you. I'll stop my signature. Looks like that's it. Martin you have your picture. Hi I was muted sorry so thank you Kati is there any other questions? Okay well on this let's later today we're going to have part two demos that's in about two hours from now so I invite everyone interested to participate in that next session and if you're looking for more resources on Jenkins uh Google Summer of Code project please visit our website we have recordings on YouTube in a special Summer of Code playlist you can find blog posts on our website as well and here's a super long list super long link to these slides so I would like to thank all our students again for their work I want to thank our mentors for making all of this possible and our org admins for all the work that's happening behind the scenes all right so thank you very much everyone thanks everyone and I think we can stop the recording