 All right, hi everybody. Welcome to Jenkins Google summer of code 2022 office hours. Today is my it's my Thursday so it's February 3, but for most of you, it's Friday, February 4. So before we get started, just wanted to do a really quick introduction so that you guys know who's who on this call at the moment. So Mark weight is our GSOC mentor. Chris Stern is also our GSOC mentor plus our org admin for this year. Natasha is a mentor. And I'm an org admin. So, I mean, we are recording this session as you saw, so I will put the link in the Google Doc after the session. What else we will start on time we will end on time. And if you have any questions, please feel free to put them in the chat window or unmute your mic and ask your question. I'll put together an agenda, but Mark talked me out of the out of the agenda and said, given that this is our first office hour. Let's open this up for a casual conversation just ask questions of our previous GSOC students like Natasha and Chris, who are now mentors, and ask the mentors whatever it is that you want to ask so that we can help you in this process of your application. And I'll leave it as that. We see how many people do we have we have seven participants. Yeah, and if, if there aren't any questions immediately list it's perfectly fine if we go into into the topics you had on the agenda. That's great as well. Thanks Kristen for joining us also so we've got Kristen wetstone another mentor who just joined us. Thank you. Hi, Kristen. So let me share my screen so then I can share my. Okay. This aside. I had put some just based on some of my digging around of previous years, office hours GSOC office hours. I thought it might be helpful just to add some helpful links to our beginners or applicants. The helpful links here are what was, what was the outcome of previous years just to give you an idea of what to expect this year. What are some project ideas that we are that has been accepted for this year, how to propose your project ideas, where to have an open discussion on GSOC. And then simple guide and how to get started. So I'm going to move on. So please ask your question. Stop me ask your question. Any time. Okay, so then we will let's start with our discussion for the project ideas. The first one is automates automatic specification generator for Jenkins rest API. And I believe this is marks and Christians. No, actually, I think that is so why don't you click that link and let's follow it. So open it up. This is one that I think Kristen Kristen knows and go ahead Kristen. Yeah, cool. Yeah. So, um, the goal of the kind of behind this is that there's a bunch of rest API's that are available, kind of the different plugins have or core, and what we would like to do is be able to generate help pages and stuff on the website, automatically. And we'd also like to publish it kind of in a format that's easily consumable so the open API standard open API three, or sometimes called swagger but the official ones open API three, just to help document it so it's easier to read and it's kind of with a standard. So a lot of this is going to be identifying. We have a kind of tool ready that goes and generates the pipeline steps for the different plugins so probably be doing something very similar but focusing more rest, and then being able to kind of tie that into how the build is done. And then also, yeah, figuring out what we want to have for the different HTTP responses and pieces. I think you can go right currently if you have a system running. You can actually see like the rest API for your specific Jenkins instance, but we're trying to do it for everything. So we want to know like what are all the different options and like kind of the plugins that you can install to be able to get those different pieces. So, this is a good introduction to being there's doesn't necessarily have to be as a, the project probably will be in Java, that type of stuff but there's chance to be able to also work with rest be able to figure that part out. Yeah, so, so when I when I think about this particular project. I remember being completely enamored with and charmed by the, the rest API in Jenkins because when you open up the Jenkins UI, there are rest API links at the bottom of almost every page. And it gives already some automatically generated documentation right there, but this is proposing let's take it to the next level and comply with open API three with a swagger spec, and have that published separately, so that it's available from the assembly of all plugins and available outside of a running Jenkins instance. I think the project ID is really cool. And we would love to have someone take it up and turn it into a project proposal for the Jenkins project and G SOC. So Mark we have I think, and raise. Is there a specific Java framework associated with the rest API. Christian you want to answer that that's a fun question I like that. Not necessarily this is, or at least I dig into a little bit more but mostly this is just kind of dealing with the plugins as they're already existing like and the structure of stuff is kind of expected output would be something that can be posted, like I think that some of it is like documentation on the website. If we want to also tie in like open API spire into Jenkins itself, as long as it's able to kind of be displayed. It's kind of working within the framework of Jenkins and then also like on the website I'd be more like you're producing some type of markup document or could be ASCII doc but I think markup be better. But that's going to be probably more of a static piece and probably actually like an actual open API document that can be posted on the website but no specific framework. Yeah, so I was thinking that what Veehan was asking was the framework that's used to generate it and I thought that was somehow stapler now maybe I've misunderstood. The rest API is actually defined. Is it is the rest API and Jenkins actually defined by references to stapler or have I misunderstood. That is stapler. Okay, I haven't said that in a while but yeah. Okay great so Veehan hopefully that answered your question. And don't be shy about unmuting yourself. This is, you're certainly welcome to unmute here. Oh great understood super. And waste to some sweater. Hi, hello everyone. Really, I was interested in this project and I wanted to ask that as a part of the project that we supposed to make a plugin that would extract the specifications for the rest API, and then give the HTTP response. I don't necessarily think so because the stuff already kind of exists right like the whole we want to kind of is present we just need to be able to get the information that's already there. And you do not have to worry about like installing a plugin in the Jenkins because like, if you, as Mark was saying with you can actually go and like see the rest calls that are available, like in your as I don't have a good example of a thing that's running right now but I think further in the project details there's a if you run your own Jenkins instance and pop it up. There's like a URL that you can hit and you can see like what it would be like for your specific install so what we're kind of needing is something that can take what's already kind of generated. It might end up being the stuff that you end up publishing on the website would probably be more of just kind of a. I would take inspiration for what we do for generating the pipeline steps help. I think, like for getting this swagger piece, it might be something that we can try to do with, I think core in core. So I might be able to add part of that stuff to core anyone necessarily need a plugin. So sweat, I would reinforce what what Kristen said that this is this will be a tool that runs outside of Jenkins, but reads but couldn't can use Jenkins source code can use Jenkins API's to generate a list of or a description of the rest API's that are available, but it actually isn't running inside Jenkins naturally the, the, the example that I think Kristen referred to earlier of a possible idea of how this might be done was there's a thing called the pipeline steps documentation generator. And that pipeline steps doc generator is a tool that runs outside Jenkins periodically we run it every hour every four hours or something like that. And it reads in all the data and generates content from that data. So it's not a plugin in that sense. It's rather a separate program that reads data and writes data. Thank you. Thank you, Mark. That helps me a lot. And if it would help I can actually show a Jenkins instance with some of the rest API's of the rest visible if that would help Alyssa. Yep, I stopped sharing. See you. Okay, so here's, here's my and you would see the same thing if you were to run a Jenkins installation yourself and you should run a Jenkins installation. It's a good thing to do. This is a Jenkins installation running on a public URL that I happen to maintain and here if we look the bottom right hand corner is this rest API hyperlink. And this thing gives me all sorts of really. Okay, here's the documentation describes this and and oh by the way if you use this these options to which you can do this example you can do this. And so here are all sorts of things already available just by navigating and what this hints at is that these API's are discoverable by Jenkins itself. And the reason they're discoverable by Jenkins itself and generated by Jenkins I think is because of the stapler framework that goes around and looks for them. Kristen did I describe that correctly or if I missed something there. Yes, no, you got it. And then you can click on like you can see different pieces about like the XML then the JSON and the Python but we're probably not really going to focus on that those parts as much. Or like those are kind of, yeah, as you can see the further separate links but it's just kind of this is just general information and it'd be nice to be able to see more about what you can do. Yeah, the and what this what this hints is that for many, many places in Jenkins, I can do exactly this and oh hey there's XML data at this level it's telling me about all sorts of labels on my agents and all sorts of so so many different levels have have the API is available and you can use them directly. It's just sometimes difficult to figure out what the descriptions and it's not as maybe obvious. Compared to the thing there are certain standards that have been published it's like if we can make it match like format that is maybe familiar. It's easier to be able to use API or share share the document or just kind of like share the knowledge of like what you want to work on versus having to, you know, maybe parse the XML, manually or the JSON and look at it to figure out what you're trying to do. Right. Thank you so I stopped sharing a list of back to you and we've probably given that we're now halfway through we've got we've hit one topic we probably want to go on to other topics. Sorry, I need to take myself off mute. So the Jenkins file runner action for GitHub actions and this one is Chris and oh like but Chris, this is since you're here. This is all yours. Okay, so this is based on a POC that was done, I think, maybe two or three years ago. And you can see link. Where's that's GitHub actions POC for Jenkins single shot master so could you click on that one. This one. Yep. Our end goal is to have something similar to this, except the content will be all different. So in the end they'll be use this GitHub actions with a project the same. So this is what we'll see. And so let's look here so this is quite like quite raw because like before we didn't have Jenkins file runner. Now we do So, um, so this is like just POC so a lot has to be changed. And this is basically what what we can do. So if in case you're interested in the area you should start with this. Maybe you can scroll faster to the end, because it's just. Yeah, so it's just we only have one action. And I think for in our case we can have like similar this one. And this one is one you're bound to so we for our project we can have it went on say back Linux and windows. And let's go back. After that. And then let's go back to the part project idea page. Okay, so if we go to Jenkins start when a project that hyperlink above what we saw before so this is what what's new after the POC was done. So this is what we're based on to to start on like Jenkins file. It's just a runner action. And the last release of this, as we can see on the right hand side is August 30th, 2020. So it's, it has been maintained until quite recently. And so if we can go all the way to the bottom. So, as you can see here is it is an incubator project which means it's, it's quite brand new. It's, it's still in incubation. And for if you can, if you see in the, in the section titled using Docker, this is only like, and in this repo is only the distribution. Yes, go down. Yeah, it's like, it's quite a lot of details here, as you can see. Okay, so you should talk here and then with this revision. But we want to extend this possibly to include like other distributions as well or instructions for people to follow to extend it. And because we're like right now that the instructions are not that complete. And we have to base like office and to create actions for GitHub actions. That's the basic idea of the project. So it's quite detailed here because like, I think all I was working on this before, like, before the schedule changed. Secondary pool of time after entering. So part of your roadmap is what, as you can see, like, that one is what, if you're interested in this, you can sort of this and see what is in the works and what's been planned. And also for contributing different instructions. So you can see here, contributing guidelines. So it says here, if you are interested in, like, getting started, so it tells you what you needed. So basically, JDK eight or 11. Maven, like what I used to it as 3.8 point for the latest version. ID Docker make and they also have documentation for this so it would get started. See it develop documentation and building as the most important part possibly because like you want to check out how to do it first. We've tested it and we. I think it like for for this to work to build successfully you have to do pseudo before like before commands here. So MV and clean package, you have to put sooner in front. And for the building document just, I think for the document is we have to work, we work at a little bit because like for the last time I checked it's needed some upgrade. So debugging guidelines, you know, testing changes. So it tells you what we can do the test and proposing changes that this is what you need to use quite a bit. If you are like to work on the project idea because like what you may need to like submit all the PRs to these workers as well. For continuous innovation so. So job can be seen, like, and where it starts here. The code for store in jeng's phone, possibly would. So a lot of the details can be seen in jeng's phone. Okay. So this is like the like we can see the test results. If you like some people request, you can check him the status. Commit the branch message intuition and complete time. So this will help you work quite a bit. I think we can go back to the project ideas right. So, if you go to new be the second, this has to be so long. Yeah, new be friendly issues. So if you want to get started, you can like check out some issues at this link. And for, you can see, like, bunch of like issues, all able to first could issue. So these can get started to get familiar with the code base to you. And so, like, and let's see so skills to improve and study. So basically it's based on Java. But doing good, like a lot can fake to be done to like including Docker and get up actions. And my co mentor, my potential comment was like, but he's not available today. So, he can show like some of the time. And for portrait things, orientation lines, they saw like the same for all project ideas. And I think that's like most of the things I need to cover any questions. And this, I like that you you pointed the potential contributors to the, the friendly issues so they would just pick up one of those and submit a poll request to work on that issue, or they could engage with us that way already just and get involved, and gives them experience with the code base anything you would suggest they're a recommend of Oh, use these techniques or those techniques to become aware of what's happening in the code. Yeah, yeah, that's a good idea is like, we have a channel on get her. We can talk like through some issues that first before like, if, if they if the student or the contributor wants to start an issue on their own they can do that, we can work together to like to submit podcast that way. So I can, like I can put submit the finalized version, or like, they can do it themselves. So either way. Excellent. Thank you. Thanks very much. Thanks, Chris. So the next, the next item is the pipelines that documentation generator improvements and I believe this is yours Mark. Yeah, so so the, the Jenkins pipeline is a domain specific language that is extended by plugins as they contribute functionality to that domain specific language. The plugins as they contribute that functionality can also provide help. And, or in many cases, not provide help, but they can provide, they certainly provide keywords arguments that help the, that allow the user of Jenkins pipeline to perform the operations they want to do in their Jenkins file. The Jenkins pipeline step documentation generator reads from the set of all plugins that contribute these pipeline steps and formats their documentation, so that we can present it on the Jenkins website. This project is to search, search for ways that we can improve the layout, the presentation and the under the comprehension of of that documentation. So on this page, I want to have you open the most terrible horrifying one in the middle paragraph it says for example when you read the read file step documentation. Not that one but the next link after it when you read the checkout documentation. So click that and we're going to wait for a little bit. So this is an example of, of an awful lot of information presented in a rather difficult form to consumers and one of the things we would like this project proposal to consider is, how could we do this better what is a better way to present this information that you're going to take, you're in a perfect spot there on a very near the top of the pages get SCM expand the plus to the left of that thing. This expands into what feels like a book, one click expands into this enormous thing, and there are about 60 other things like this on this page. It's just too much information for one single page. So the project is to find better ways to present this, this kind of information, so that it's more easily navigated by users. Kristen insights from you Kristen Kristen was the one who was brilliant enough to create this tool I think the tool that does this is awe inspiring because it actually knows how to search through all Jenkins plugins and extract this documentation live. It's wildly cool what it does. Any insights you want to offer Kristen on how the project might go. I marked like brought up a really good page so it's really cool that we can like go and look at all the different stuff in the different plugins, but it's really hard sometimes to make it appear very cleaner cleaner way here. So, I don't know if like I think a lot of it is going to be figuring out how to maybe tweak it to be a tweak the tool to come up with a better way to generate the pages and maybe also honestly like figuring out maybe a better way to display some stuff so but I think there's a lot that and maybe this also involve us going or whoever is exploring this to also go and figure out maybe how to like improve some of the documentation for the specific pieces that are providing problems so maybe there's just better descriptions or even kind of just helping figure out what's going on so you're not ending up with a huge page of lots of things twisties to open up that kind of give all the different options it just might there might be a better way to display it on the page. So, yeah, so so for me this one has an elements of not just Java design but also web page design and information navigation. And it's not this is not just a coding exercise right this one is a think about how you would design something that human beings would enjoy reading and and would have a better layout. Now I'm notoriously bad at that kind of thing so this, but I think this this is a great example of the full breadth of kinds of things that can be done inside a Google Summer of Code project. Elizabeth, if there are questions happy to answer them but given where we're at on time, it may be that we call this good enough and plan to meet again for our next office hours. Yes. One minute left. So, I will carry this over to our next meeting. The next meeting is going to be. So, next, February 10. And it's at UP. 2pm UTC and me a time, and then we will be alternating so if you are checking back on the agenda of your you can't make it to the me a time to circle back to this document, and I will have the next meetings for Asia and me a following that. So, thank you all for joining us. Have a great day and have a good night. Bye everybody.