 Welcome to Google Summer of Code. This is the Jenkins Office Hours. It's the 13th of January. Thanks for being here. Let me bring up the agenda topics and we're open to topics that you would like to add. Jenkins Project, Google Summer of Code. We just released Jenkins 2.263.2 today and Jenkins 2.275 with security fixes. So it's been a busy day so far for me, watching and being sure that all the parts and pieces are behaving as expected there. Forgive my not being as quick on this one as I should be. Here we go. Let's see the meetings. Congratulations on like new release then. I should say. We like that. We like that a lot. Oh, nope. That's the recordings. I need the notes. I know that I have notes. Well, I apologize. I am not finding the GSOC notes. We use a Google Doc file and this is really awkward. I don't find the, oh, probably in the event calendar. Just a minute. Let me check there because I could just read that yes, meeting minutes of course. If I would read the calendar, it would also help. Here we go. All right, so I'm gonna share my screen. I find that it helps me if we have a shared copy of the agenda, we look at it together and then we'll type notes. So January 13, 2021. And let's make the text big enough to read. And now the sharing thing. Share my screen. Okay, so you should see January 13, 2021. Is that visible to you? Yeah, it's good. All right. Super. So status updates, discussion. So one that if you are interested, I could put a discussion of the most recently added project idea. Yeah, that could like, will be a link, please. Get credentials in a pipeline step. But rather than me spending time talking about that first, are there other questions that either of you have that you would like to put on the agenda? Yeah. I studied the project. I studied the project that was automatic specific generator for Jenkins REST API. And I have research about quite a lot of things. So I have a few questions. And like on that project idea, there was one video which is referring to YouTube from 2020 discussing about that project idea with the potential students at that time on 2020. So at that time, Olexer said that we need to, first of all, a good step to get started on that is to just work with get APIs with you using Salesforce to get annotations and just started making specifications. But on the other hand, at that time, another potential mentor, which is Christine, also said that you can use OpenAPI to publish, I mean, documentation. So I was a little bit confused. I mean, I have research a lot, but I'm not sure again, where to get started on that. And I think the answer there, as far as I could tell, is that neither of those is particularly preferred. Both are potential. So as far as the mark understands, either path will be helpful and may give you insights on what will ultimately be the path that you choose, that you would choose in your project proposal. Because I don't think that Kristen had done the full, the full steps there to confirm it. And I'm pretty sure that Oleg hadn't done the full steps on the says pause thing either. Ah, and Oleg's here, so we can ask him directly. That's great. So Oleg, Segar was asking about the automatic specification generator for Jenkins REST API. He'd started using, well, Segar, you should explain. I shouldn't restate what you did. Yeah, sure. So hello, Oleg. So I studied that project in which we have to extract REST API from the sources and then publish the REST API documentation. So for that, on the project today you have mentioned you have to study Java REST API and OpenAPI slash Swagger. So for that, I have watched the video which is in the projector idea which is directed with the YouTube in which you are talking about that project with Kristen and the potential students in 2020. So on that, at that time, you said the first good set to get started to have a good understanding is to generate specifications using says post which is going to capture the annotations and through that you can just start it with the get API. But on the other hand, there is other part of the code also which do not have annotations for which I have to, I need a complete analysis of the project or maybe some annotations also to get started. So, and on the other hand, Christine, I mean, when you said to Christine at that time, what's your perspective to get this project done? So she said we can use OpenAPI to generate the documentation. So I was little bit forgetting just started in that. So from where should I get started? You know, research further where, I mean, I've watched all the resources that I can possibly search. Yeah. And thanks for doing this research. So again, you're totally right by referring to these videos. So yeah, says post was just an example because says post allows to capture easy beats. So items which are annotated and hence, which you can easily extract from the code. Unfortunately, our framework which we use for the REST API step here, it doesn't always provide explicit endpoints. Though recently it improved. So if you navigate to the Jenkins code base, you can see that many requests annotated by post, by get and you can capture data from there. And maybe one of the approaches is actually annotate methods, which I'm missing. Because when you go through class, you can easily determine that the method is used for endpoints. For example, it has annotation or it has specific parameters like just query parameter annotation, et cetera. All these methods immediately become a part of REST API. And in addition to that, you have getters and the getters also document the step. So by taking these three types, you can cover significant part of use cases for Jenkins REST API. No, it won't be complete. But at the same time for other use cases, maybe the good approach is to just annotate endpoints property if something is missing. Okay. So if I have to take another one step, so should I get, I mean, study the code base of Stapler or start it with Jenkins code? So my recommendation would be to actually start from relating this small plugin. So you can please repeat that. My recommendation would be to start from a plugin. So for example, you can get plugin or maybe something smaller. So something which has REST API. And then you can just add dependency on this plugin, add it to class pass and do some stunning. So there are already some tools operating in this way. So you have seen references to pipeline documentation generator, right? Yeah. So I can find the link. So basically you could take a single plugin, not necessarily the Jenkins core. Jenkins core is just a big tonalize. And you can take a plugin and try to build an example which is based on code base similar to pipeline documentation generator. So should I just pick, let's say one, any plugin and use a get plugin and then I try to generate the specification for that kind of plugin, for that REST API, is it? Yeah. It would be one of the most simple ways. Okay. And again, pipeline sort of get plugin might be a big. So you can take something smaller as one of the options. Okay. And in that, I mean, you showed that in that time you're using some who am I page which is showing the info about your get info, okay? And so is that also a plugin that who am I? Should I get, I mean, try to generate specification for that, who am I? Well, you can do that. Though for my page is really straightforward. Just a second, I'll open the code. No, Mark, are you looking for the code? I was not looking for the code, but I certainly can. Well, like just a minute, let me. No, I can do that. Okay. Yeah. So, oh, not Jenkins.io. It's Jenkins. Core. Yeah, just didn't want it. Yeah. It's just go to fire for my Java. So, yeah, thank you. So is this, is this the right page I like? Yeah. So if you scroll down, you can see some examples. So you can see that it's exported beam. It's extension. So it allows to make your map to the endpoint because I'm perfect for action. So it's just for my. It's exported beam. It means that if you navigate to that using JSON or XML API, you get the response. And you can see fields which have been exported. For example, getName is authenticated, is anonymous. And this is basically the information which would be exported through REST API. So, yeah. Oh, like would it be okay if I brought up my Jenkins to show how the experience interacting with it for SEGA's benefit. So it's, I think SEGA, what you'll see is something like this. So this is my Jenkins instance. And I'm going to append on to the end of it. Who am I? And this now has the AP, this is the webpage rendered. And if I do API on the end, oh, like I think that shows me the REST API hints. Now you need to go to JSON, for example. Ah, so if we go to the JSON API. Yeah, there are three additional types. But yeah, API slash JSON and you get the API response. So basically these three fields which we discussed. Ah, yes. Okay. And there it is without the pretty. And there it is when done pretty. Great. Yeah. Okay. So I have to generate that JSON specification, right? Not JSON specification, but yeah, this is a JSON response. So you can document the open API specification. So basically by processing connotations, and for example, by extracting Java doc as documentation, though you can see this is not the best example because there is no Java doc. Well, but, and this would be, it would be valid for him to add Java doc to this, to this class, if that helped, right? I mean, he could submit a pull request to who am I proposing to, to Java doc it, but I think like the point is valid that if the intent is to use Java doc, this class won't do that as it currently sits. Yeah. Anyway, he's just an example, but so. So, I mean, so basically I have to, eventually I have to generate the documentation, but in order to generate the documentation, I need the endpoint. So through here from annotations, I'm just trying to capture the endpoint and try to parse that into an, and from that endpoint, I have to generate the open API specification. And from that specification, we have to generate the documentation. Is it? Yes. So once we've got the API specification, the documentation can be generated for you. Because there are tools for that. Okay. Okay. So, so basically I have to capture the endpoint and try to generate the open API specification from that endpoint. Yeah. And the good step is user to get started with the, pick any small plugin and try to capture its endpoint, gata endpoint and just generate open API specification for it. Yeah. So you don't have to complete all the project during the application phase. So it's just a discovery so that you take a look at options and you can come up with a better proposal. That's it. So can you please repeat that, Sury? So the coding phase happens in the summer. Before that you basically explore the projects, explore the opportunities and your main goal is to understand how to implement a particular project and come up with a proposal. So for example, here, if you see that this approach doesn't work, you can make another proposal. Now that's perfectly fine. And again, yeah, this open API is a quite wide area. So that might be other topics. And so, okay, okay. So the goal to restate, Oleg, the goal in this phase is to prepare a persuasive, thorough project plan, right? Is that a fair way to say it, Oleg, that one of the objectives here is- Even with a detailed project plan, but basically to form an understanding what would be the deliverables. So for example, you can take a look at the pipeline step recommendation generator. Maybe it could be something like that. Maybe something different. But yeah, the goal for now is basically to see what are the opportunities and come up with such a proposal. Okay. So basically, currently I'm just trying to research more and more, but are the possible ways not have to worry about the coding stuff, is it? I mean- You can prototype, but the goal is to basically explore the area. So- Okay, I see. I see. Okay. You don't have to produce, let's say, a solution for the problem to get accepted now. Basically, your goal is to focus on the proposal and to collect information which you need. And if creating some prototypes helps, then you're welcome to do that. No, okay. Got it. So for now, I mean, for just- I mean, to just start more exploration, can you recommend me any plugin, small plugin? Should I? I mean- Well, so how I could do that? I would go to Jenkins and just search for exported bin. Oh, so looking in the Jenkins GitHub repository. Yeah. Well, for example, there are plugins which are quite popular now, like configuration as code plugin. So it would be a good starting point. Because in it, there is probably an exported bin annotation that would indicate, oh no, I make a mistake. No, there is no exported bins. So there is one class configuration as code Java which exposes API. Ah, okay. But yeah, it has no data export to API. So, yeah, this plugin doesn't work for that. I'm looking for alternative proposal. Okay, so I mean, is it worth a look at the Git plugin or even maybe at the Git client plugin as, I wonder, well, you indicated that Git plugin might be too large. Whoops. Would help if I navigated correctly. So we basically need a relatively small but at the same time useful plugin. So yeah, there are many plugins which have exported bin annotations. Yeah, I'm actually curious. I wonder if my friend, the platform laborer has an exported bin. I don't think it does. No, it doesn't. Okay, but does it have any post? It does have a post. So is that might be one, oh no, that's just in a test. So that doesn't help us. This is only a test implementation of some other post. Okay, nope. Yeah. I have a question like what the annotation exported bin, I mean, what is it, is it representing that particular exported? Yeah, it means that the steppler can export this class on Git request. So basically you can export data from this class when somebody needs metadata. And that's probably not the most popular case because in many plugins they just receive commands. They don't export the data. Okay, so a steppler is using it to export data, right? Yes. Sorry, I mean, if I confused, I mean, if I'm a little bit confused. Yeah, that's fine because you want, yeah, so we still need to find a plugin. So, oh, I guess I look at the Git object inside Git client plugin, it's definitely got exported bin. I don't see any post on it though. Should I post? Well, Git plugin, that's gonna have some post. Yeah, absolutely the Git plugin I know does. I was just thinking Git client plugin as a smaller plugin. Okay, so let's look at, so for example, here is form validation inside, inside one of the browsers like... Maybe they should take away that if there are not so many plugins, it's working data, maybe it's not the best use keys. Yeah, maybe. So you could take one of pipeline plugins, of course. Okay, yeah, I'll try to find something, but again, I'm just looking at plugins and I cannot find anything that is interesting to export the notifications. So, yeah, maybe actually taking an agenda score makes sense there, okay. So, okay. So Segar, you had described the steps to attempt and I wanted to capture those and I wasn't typing nearly fast enough. So I think what you had said was the first is use the who am I based on Oleg's guidance class as an example in Jenkins Core and you had noted extract the API endpoints, endpoints as or describe them as open API or maybe I'm getting it backwards here. So extract them and describe the API endpoints with open API, then I assume you've got to find some way to extract, so that would be an interactively done. Then you extract them, the API endpoints programmatically and that was where Oleg was suggesting the pipeline step generator is an example of something else that does that. Oleg, did I understand correctly there or am I going down the wrong paths? That's fine. And then, okay. Oh, finally, I found plugin which is good. Yeah, it's a quick coverage API plugin. Oleg has multiple exported beings to generate a report. Okay, so code coverage API plugin. Code coverage API, so I mean, okay. Like coverage trend. So from this plugin, I have to kind of extract the endpoints and generating the open API specification, is it right? For just a exploration point of view. Yes, I think you described it, Segar. This plugin gives you an example of a place where you can use the exported being and exported annotations to identify things that are providing data. Now, Oleg, I don't know how to reach this endpoint from inside Jenkins itself. I'm sure it must be reachable. And is that... From Jenkins, you need to publish the first report. And yeah, after that, so we can now see. Maybe I should just pinch, yeah. Okay, yeah, I'm happy to stop sharing in a second. So do you see my screen? Yes. Okay, so here we have exported the being. So what Mark was showing, there are multiple entries. You can see that basically all of them point to coverage result. So coverage result here, it's basically a model object. And you can see if you go here in coverage result, then you should have exported things for other data fields. So, for example, coverage tree, which is also exported being. So what happens if you go to the center point, you get coverage result. And then on the next level, you get coverage tree. And the coverage tree includes other classes. So basically you'll get a hierarchical structure. It's a lot of data being generated. So here there will be JSON field results, which includes more fields underneath. How to access this data? So coverage result, it's model object. So it's available on the top instance. I believe it's available through action. So let's check this theory. So yeah, there is a coverage action. Actions are exported through API. And here you can see that there is a coverage result, which is get result. So what will happen here is if you navigate to coverage result page and then go to result, you will get this report, which is a part of API. I'm not sure. Do we have coverage, just coverage API setup anywhere? I guess the Jenkins follower does have it, just a second. And I thought that I was using coverage API on my instance. So while you're looking, I'm going to look, Oleg. Yeah. I think it is, yeah. So here's our coverage report. So it's slash coverage. It's coverage action. And we have a report here. So you can see that you cannot access it actually through the web interface, but I believe that. Yeah, ci.jenkins.io may have maybe limiting intentionally the APIs it's publishing. Yeah, it limits a lot of the APIs. But yeah, there is no REST API exposed for this data. So I believe it gets just queried through REST. So, yeah, probably not the best example either. Let's see if I need to meet with, actually you can see that it's already get result. So because it goes to target. So maybe we could just extract it. Yeah, you can see that API JSON works. So if you invoke it on your instance, you will get data. Here, basically the data is filtered. So we get nothing. So you can try this URL, a similar one, camera coverage API JSON. I mean, you'll be able to get to this pre-structural data. Okay, and Mark, the recording of this video is again is going to be at Gitter, right? So I'm just going to watch it again to understand. So there's a reason why we record these sessions. The recording will be available probably within two or three hours of our ending. Absolutely, Sagar. Yeah, yeah, okay. Yeah, sorry for explanation, yeah, I wasn't prepared. Actually that was marvelous, Oleg. Thank you very much for taking us there. So now Oleg, the coverage API that you were showing, that's different than the Jacoco coverage that I'm using there. That's an entirely different thing, right? That's, yeah, that are two plugins you should separate. I see. And so the coverage one is the newer of it, great. Thank you. So, I mean, I should explore the coverage plugin, right? Yes. Okay, and try to extract the, and Oleg, I mean, why are you saying, I mean not saying, but you said we need to extract the JSON tree, but in order to generate the specification, we don't need the, I don't think that we don't need the response body, we need the API endpoint in order to generate the open API specification. So basically, we just need open endpoint and from endpoint, we just wanna somehow integrate the open API specification in our code to generate that specification from the endpoint. Yeah, that's correct. So yeah, the main problem is to find this data because as you may have seen, sometimes it's not trivial, but yeah, in many cases, you can just add additional annotations. Okay, okay. So in Jenkins, yes, step-by-step is basically talking directly to Java. So unfortunately, we are not using Spring or Quarkus or whatever for the Jenkins core. So it's more difficult to capture. Where the endpoints, but again, I believe that string annotations in theory, we could adopt them as an experiment. So, but today's implementation really is based on the Stapler framework and there are 15 years of code that is tied to the Stapler framework. So having Segar and others who are exploring this idea, know that the REST API is generated automatically in Jenkins by Stapler reading the Java objects. Did I state that correctly Oleg? Yeah. Okay, that's great. And in that video you said, I'm Stapler, what is doing? It is kind of a data mining who is just, I mean doing two things basically, kind of converting the REST API endpoints into Java objects or Java objects into endpoints kind of, is it? Yeah, well, it does a lot more, but yeah, basically it's binding for requests and for data. Okay, okay. So, hey guys, sorry, I just got to know about this meeting. I, like I saw Mark's message on the group and just joined. So if, so there are only like three minutes left to the meeting. If I wanted to discuss a few GSO project ideas, if that's fine with everyone. Yeah, maybe one question we use comes so much than this REST API. Maybe Mansoor has any questions. Just try to unbox and go ahead. Actually, yeah, I had questions like I had a question regarding different idea, like information was there, like if there's like any way I would like ask it to be mixed or anything. There is no any way I would like to answer. I'm sorry Mansoor, I'm having difficulty understanding what you're saying. My apologies. The audio quality is a bit. Me too. Oh, okay, okay, sorry, sorry. Now, is this the main quality? Am I doing? No? Okay. Very soft now, Himanshu. No noise, but very soft. Hello. Oh yes, that's it. Got it. Okay, okay, okay, okay, cool. Thanks, thanks. Actually, I did change some settings in mic so that must have affected it. So is there like time, still time? Can I ask my question like, is it related to plug installation manager? There is time and I think at least for me, I am willing to continue for at least another 15 minutes. Oleg, I don't know about you and Kara, but I've got time and we could continue. I'm happy to continue as well. Okay, that's good. Thank you so much. Also, yeah, I was doing like, I have been following this project, plug installation manager project idea. Then there's like, I was doing what I should say, I was preparing and preparing for this project idea. And in this case to study and improve, there is mention of Java. Like, I would like to ask, is there any particular framework that you would like to suggest for this idea, like spring or anything for this particular idea, plug installation manager to me? Like you have mentioned Java, but Java is like so vast, so that's fine. So if you're looking for modern frameworks, it will be like, yes, spring would be options, you can also consider Quarkus. If you want to work with it, yeah, Quarkus is one of the... Sorry, I didn't cut. Quarkus, okay. So this is also a framework you could consider. Yeah, so basically... Yeah, please. You were saying something. Yeah, I just wanted to say that, yeah, this also is also quite popular framework these days, especially for cloud native applications, native support for, well, basically support for building native images. So if you want to explore this option, it could be doable. Okay, fine. Like along with this, any other that you mentioned, and I couldn't keep up with it, Quarkus and any other framework that you mentioned, and I did not like... For CI applications, yeah, there are not so many frameworks. So, yeah. Quarkus. Yeah, one of the problems with plugin installation manager that has a pretty bad CLI interface. So for example, are you working it to, let's say, pick a CLI so that you have multiple commands with proper option management? It would be a good way to consider. And yeah, then if you want more modularity, you can use Quarkus or something on the top of that. But yeah, it's a separate improvement, which just makes a good difference. So like we can move directly only with Java, just with Java, or we can use Quarkus to add more modularity to our code. Yeah, Quarkus and Java. Yeah, I get that. Yeah, it's a framework on Java, but if I want to add some modularity... Okay, thank you. And... Sorry? Were you saying something? I stopped you in middle or anything like that. I thought you were saying something. Okay, fine. And you mentioned about JSON data structures, package management tools. So were you referring to the tools that were already built for Jenkins or some other tools in this case, which you mentioned? One must know about package management tools. So what kind of tools were you referring to? Do you have any idea of any examples? You mean tools for Jenkins? In general, there are many ACLI clients. There are tools like plugin manager. There are also a lot of developer tools. For example, plugin compatibility test, parent forms, different scanners. So if you're looking in the tools area, it's something I would look for. All these tools, they basically stand alone. All of them would benefit from some improvements in there. So if you're looking for related small projects, it could be an option. Okay. Okay. Okay, thank you. Yeah, that's like those were the two questions that I had. Thank you. Okay. So Hemantru and Segar, it feels like we've addressed your questions, Vibhav. Shall we give you some time and let you discuss you? You had a few project ideas you said that you wanted to offer? Yeah. Thank you, Mark. So basically, I had a few ideas regarding, like the first idea I had was the cloud events plugin. Basically, Jenkins should support like cloud events. So this would mean that you should be able to create cloud events and Jenkins should respond to them, maybe trigger jobs and stuff. So this was the first one. Second one was a project that is already there, a Tecton client plugin, and it's hoping if it could be part of GSOC. And third one, I don't know if this even counts, actually, was the Jenkins file owner operator. This is something I prototyped in, I think it was in December or November. So this one would be basically like running Jenkins files in a serverless fashion. And this is based on what Oleg built, and thanks to him for like building that awesome file runner, which basically turns Jenkins files into like serverless executions. So these were the three ideas. I was hoping if we could discuss these and maybe choose or take them. These three areas could be potentially feasible. You just need to factor them to something which can be implemented during the JSOC campaign. For example, cloud events, most likely yes, because it's a new code cloud events have a relatively simple API. So I think that prototype could be created for Decton client and Jenkins file runner operator. Yeah, the main problem is to actually define the scope. So what would a student do there? So currently, so for the Decton client plugin, there are a few things that could be added after addition of like, you know, first they could add the remaining APIs that aren't there in the plugin, then they could work on some features which make the plugin more dynamic in nature, such as preloading some stuff and everything. So this is what I was thinking with in terms of Decton client plugin. About the Jenkins file runner operator, I was thinking if it would be possible to have a UI in it. So maybe in the operator, it runs like the operator will have like the instance of an operator will have an instance of a UI also running alongside of the where the user can see like which all file runs have been run and maybe execute file runs. So this is the scope I was thinking about. Yeah, it's in principle it's possible. Again, yeah, there are examples of such implementation, for example, in Jenkins X. So I think that if you want to propose this project ID, you have just to do that. Okay. Okay, so should I create a so what I'll do then for the proposal I'll create a draft, and then I'll share it with you guys soon. Yeah. The mailing list is a very good place to share your draft proposals, and you shouldn't hesitate to make a number of proposals, especially since these all sound interesting. That doesn't mean you're committing to mentoring on 3g stock projects or anything. So this is this is for discussion and to see what students are interested in working on and we'll see what what I guess get traction and how the process goes. But they all sound like very good proposals. So thank you. Okay, that sounds good. Actually, like, it's more about like the idea that that was there and you know it should be implemented it's not really about the mentoring part, even if the idea just gets executed. It's just really nice to see that. So, just like kind of looking forward to that. Thanks. Thank you. So, yeah, close events might be interesting because it's standard one project. So the student can create it on scratch. Other projects that are also viable. Okay, so what I'll do first is I'll create the first one on cloud events. And then maybe we can start from there the rest. We can look at like I'll create them also but I'm hoping the cloud events one like I'll get to help a little on it because I'm a bit interested in having Jenkins be discoverable by cloud events and you know triggering jobs by cloud events itself because then if cloud events works for instance, someone from Tecdon or something they could, you know, trigger a Jenkins job purely through cloud events would be cool to see. So, I don't have anything else apart from this to discuss. Then, yeah, probably thank everyone who participated today. See you next week. Thank you so much for being here. Thank you so much for being available and the notes are already there. Thanks very much, everybody. Thank you.