 Hi all, welcome to the Jenkins online meetup. Today we have a demo session as a part of the Jenkins UI UX hackathon. And Kezhe will present a prototype of the GitHub checks API plugin for Jenkins. It's a part of the Google Summer of Code project. And this is just the beginning. Our coding phase starts next week. But still, there is a good prototype. And let's see the demo and let's discuss it. The floor is yours. Would you like to share the screen? Yes. So I'll start sharing my screen now. So can you see my screen? Yes. So hello, everybody. I'm Kezhe. Currently, I'm working on this GitHub checks API plugin for this year's Google Summer of Code project. And this project is still in design during the community bonding period. Well, officially start up the coding in the beginning of June. So today I'm going to show a prototype of this project now. I'm here to do this presentation because I want to invite more people to join us to tell us what you want to get from this plugin and what the API looks like you want to see. And that's it. So here I'm. So this is today's I'm going to talk about. So first thing we should start by understanding how the current Jenkins, how currently Jenkins is interacts with GitHub. So let's open the PR. So here this is the PRs for the Jenkins mustum. And so let's open up a PR here, just for example. And currently, if you use Jenkins as the integration for GitHub, you'll see there are some checks reported from Jenkins. And currently, this is achieved by using the status API. And this is the status API can only need one message for each check. So if you want to take a look at the details, we are going to the Jenkins instance website. And I think you're going to the Blue Ocean plugins page. So here it is. But the checks API is different. It can do more. So it will report the status as checks. You'll see more informations. So here, for example, I created some checks by my plugin earlier this day. So if you want to see more details, you can just stay on GitHub. You don't need to go to the Jenkins website. And you'll see the checks here. These checks are created by my prototype. Currently, I haven't provided any informations besides the names and the conclusion. So let's start. So let's talk about the checks. You see the picture here? If we eventually end up this plugin, we're able to report the warnings, like code coverage from the Jenkins to GitHub. And it will add some annotations for each line of code. You'll see some annotations like this. This is something we want to achieve in the end. So before you create GitHub checks, we have to convert the Jenkins into all the GitHub apps. I think this team has achieved this in the GitHub branch source API. The plugin, the GitHub branch source plugin, has helped to, sorry, assist GitHub. Yeah, this is the right plugin. I also posted a link to the announcement blog post in the chat. So here is the team implemented this GitHub app authentication guide. So if you want to create checks, we have to convert Jenkins into a GitHub app. And here's something you need to do. So firstly, you have to create a GitHub app here. And you can see here with some permissions to access to my repositories. And here, I install this app into my sandbox repository. And if you want some settings, here, you have to set the webhook to your Jenkins. Normally, it's like, OK, here. So normally, the webhook to receive the GitHub events is this the GitHub webhook. And don't forget to add this backslash. I remember I debug for hours because I just forget to add this backslash. So that's about GitHub apps. Here, I'm using in order to let the GitHub access my Jenkins, I use the forward delivery tool to send the events to my computer. So this is the events I received during the test. So the question is, plug-in works. Close this checks API. I can see if we're doing this fine. Yes, currently, the GitHub branch has done something like you see here. Oh, OK. I think the team has achieved some part of this. Currently, we use this kind of CURL to create check-rounds for now. But eventually, we'll add the pipeline support for our plug-in. So all this code will become just a single step, or maybe we'll even run it automatically like it currently happens. So we start with the API. Yeah, thank you. I know that code. It's mine. They are like, this is the link. And I want to say that here is something I want to get more information from the users. Because you can see now that if you want to configure checks in this Jenkins file, you have to just set this static taste. If you want more, you have to access reports from the other Jenkins plug-ins, like the warnings plug-ins, code coverage plug-ins in order to report these informations to GitHub. But if you can't access these plug-ins reports in the Jenkins file, maybe you're just able to create the check-rounds. So there's something where my team is still struggling with. So next, I want to talk about the design of my plug-in right now. And so yeah, most importantly, there are three parts, three dependencies, the plug-ins that my plug-ins depend on. And the first one is the GitHub branch source API. We have to use the SCM API implemented by this plug-in to retrieve the sources, retrieves the SHA-1 branches of the Jenkins job. And the GitHub plug-in is something we use to receive the events. Since this plug-in has implemented extension point, we just need to extend that. And we're able to receive the GitHub events from. Yeah. So here is the design of currently So most of the works will focus on this job listener. This job listener class. So there are three stages of a Jenkins run. Normally, here is when the GitHub creates the users, creates a new PR or a comment, either we trigger a Jenkins to start a job. And when the job enters a query and our checks, our plug-in will enumerate the customers to create check-arounds and we'll set those check-arounds include. We'll talk about this in detail later when I talk about the code. And later when this job leaves the pre and the stars, we also enumerates the customers and to update the check-arounds in progress. And eventually when the job completes, we'll enumerate the customers to complete the check-arounds. And at this point, we are also to collect the reports from other plug-ins, like from the warnings plug-ins, from the code coverage plug-ins to get the reports and then we send these reports to GitHub and the user will see them. So here I'm going to talk about the API we're going to provide. So you see here, this check-around results extends the extension point. So any plug-ins that want to report the information, report the warnings to GitHub, they just need to extend this for us. And so here I draw some customers, possible customers of our plug-in. And each of the customers will create a single check-around. Like for warnings plug-in, we create a check-around for warnings plug-in. And for code coverage plug-in, we create another check-around for it. So next. So now I'm going to show how the prototype commonly works. Here I create a repository as a sandbox to test my plug-ins. I create a PR area. And there are some checks, like the default Jenkins checks. So next one. So here we have two check-arounds in the same check-suit. And you'll see here there are two check-arounds because I extended from the source. Sorry for the name. The check-around source is the check-around result. I haven't changed the name yet. So in this extension point that we provide, we just currently add some abstract functions like get lane, get output, get actions. And we defer the conclusions from the build. So if it's better or it could be a success, then we get the conclusion success. And also, in this default setting, we also create the time when it's complete. So next I'm going to show how this actually works. So here when I start to use this, normally the build will trigger by the GitHub PR spot. Now I just click the button here in the Jenkins website. And it will show here. So this function is un-issualized. Because we extend the wrong listeners, we're able to all be triggered when the Jenkins job starts. So un-initialized, it enters quiz. We create the check-arounds into Q state. So here we go. We just retrieve the headshot of the repositories. And we also can get the repository names. So here we have to create the token. And in order to access GitHub APIs. So after we create the token, the next thing we do is to enumerate the extension from the check-on sources. If you see here, our first source is the default check-on source. And in the default check-on source, we just provide the name of the check-arounds. So here we created some network problems. There's some problems I'm struggling right now. Because if the method just fails sometimes, I think I'm bad luck today. So this just, never mind, I'll start it again. The access to GitHub APIs sometimes fails. I don't know why now. There's something I'm struggling to solve now. Let's see again. Let's try it again. Sometimes APIs just work differently in the debug and common mode. Because debug instrumentation creates a lot of delays. So for some libraries, it's enough to cause issues. So here, in reference. So yes, here we created the first check-on. So if we take a look at the checks page here, you'll see this default check-on is wrong. It just started 14 milliseconds ago. And if you go to the conversation card, and you see here, this checks is just in queue to the keep calling. Oh, bad luck. Sorry, but we just keep moving for this single check-on. The logic is basically almost the same. Most different is when the job starts, instead, we set the request to queue state. Now, we're going to set the check-arounds to in progress state. And we also started at time. So you see here, the time. Here is on the job starts with the token, and also updates the check-arounds. You see here, there is a circle rotating around here. And if you go to the conversation card, it's in progress now. So if we keep going. And now, we are going to complete the check-round. And when we complete the check-round, here, we just use some static like set the status to be completed. And here, we just set the conclusion for success, since it's just a prototype for now. But later, we'll maybe make these parameters to be configurable by the customers of this plugin. See, there it has stopped. So I guess we'll stop here. And the next thing I want to talk about is the parameters we can provide for GitHub check-round. So when we create a check-round, you can provide these parameters. For now, in my plan, I'm just going to split these parameters in three groups. Something is non-configurable by the customers, like the headshot, like the detailed URLs, like the status, or starting at the time. We'll do this for our customers. And another group of the parameters is the configurable ones. And like the configurable ones, like the name of the check-round, we should allow the customers to custom the name. And also, maybe some other things, like the neck and the output objects, the title, the summaries of the report, the annotations of each lines of a code, these things we need to retrieve from the customers. So this part is configurable. Another part, I think, is also configurable by the users, but will provide some different settings. So maybe the users didn't provide the conclusions for their reports. And then we'll maybe just defer the conclusion from the Jenkins job status. So that's basically about the prototype now. So any questions about this? Looks great. Thanks for the demo. One question I heard is about dependency on the GitHub French subs. So do you consider moving up our identification support outside of GitHub branch source? Or do you plan to keep it there, let him? I'm sorry, I think I don't understand. Yeah, so GitHub checks API plugin. Currently, it depends on the GitHub branch source plugin. Yes, we have to use this GitHub branch source plugin in order to retrieve the headshot, because this has implemented the SCM API. So I think we have to use it. Does that answer your question? Yeah, it does. So I was wondering whether the plans to detach that for the plugins. But if not, I think that it's a great thing anyway. But also, there's another part that we have to depend on the GitHub branch source is, I think, I mentioned earlier, is we don't need to, yes, the branch source has implemented this app authentication part. So we just depend on it to use that part. OK, thank you. That's it, OK. Any other questions from others? Hi, I had one question. OK, so KG, so I was wondering how the implementation has been done. I mean, how is Jenkins reporting the GitHub checks API? Like, is it has to be specifically mentioned in the Jenkins file? Or does the plugin automatically handles this? Yes, OK. I think my mentor has opened a draft PR for this. So here's some preview of this API. So here, so we should assume this class has extended the check-in results, extended our extension point. So when the jobs finishes, it should have set the status, set the checks, and set the summaries. And also, check the annotations. And sorry, I started all the work again. So there are some check-in results, right? So first, when the Jenkins job starts, we'll attach these results to the run through this check-in result action. So later, when other plugins have something to report, they can just get this action from the run by just the get action function and the method. And then they can get the result part from the action, and they can do something changes in this run result. So when the jobs completes, we just invoke those methods, like get annotations, get output, and then we just report them to the GitHub. So does that answer your question? Yeah, it does, somewhere. OK, that's also cool that it can be extended and modified, et cetera. Like from the users of GitLab Brand Source plugin, what I have understood, maybe it's not very correct. But what I've understood is, majorly, what user wants in the statuses in their source code manager, SCM, is like the stages of their stages that they have defined in the Jenkins file. Like, suppose there is two states, like build and deploy, they want two stages in their SCM that says build has passed and deploy has passed, and all the details related to that. So suppose this is the scenario that I want, like I want the status of build and deploy stage. So do I have to mention it in my, I mean, do I have to specifically write a build step to, I mean, a pipeline step to provide the SCM the status of that particular stage, or plugin will automatically handle that? I think most part, for the customer plugins, I think like for the warnings plugins, after the, like in the build step, there were some, like in the publish step, they should report this, change some properties in this class. And so, later when we invoke this method, we can get, but in the pipeline, in the Jenkins file, I'm not sure we can achieve that because if we want to report the information to GitHub, we have to, in the pipeline, you have to provide some warnings in the pipeline. But if you can't access the warnings in pipeline, and then you can report it to our plugin, then we can provide it to the GitHub. So the pipeline support was still discussed with my mentors whether we can, how we can support the pipeline and whether we should support the pipeline. So, I'm not sure whether this answers your question. Yeah, it again, somewhere does. So, like all the checks, the result sent to GitHub is done by plugin automatically, like doing, running the job it sends, started, and finished or like other results. So, is it done by plugin itself or that has to be mentioned, needs to be mentioned separately in the Jenkins file, like you had written a curl command in there. So, we have to specifically mention it in the Jenkins file or does it, does the plugin handle this? Okay, so the listener that KZ has implemented, it's mostly in the, like for the job, like when the job started and when the checkout, like for SCM on checkout and so like, it would be nice if there would be listener on each stages and reporting on that. So, I was also wondering how is it doing that if there is... Yeah, it's a good question. So, let's wait for the catcher is able to answer it live. If not, you will just take it offline in the chat. So, meanwhile, if you want to know more about this project or if you want to join that, there is a mailing list. We do it as a part of the platform seek at the moment. The results chat on Gitter, where you can find all the information and when you can chat with mentors and with other stakeholders of the project. And if you want to join the meetings, there are weekly meetings on Wednesdays. So, you can just join the project meeting and see the recent demos to discuss the status. Okay, so, okay, should we take the question offline? Yeah, I mean, we can do it. I think actually, like, Parachay's questions answered a lot of the questions I had as well, I think. What I'm missing kind of is like an overall workflow. Like, there's a lot of technical details here of implementation, but I have similar questions. Like, what's the actual, what would a consumer, what would an end user of Jenkins, how would they use this? Like, if I install this plugin, will it magically start reporting my warnings from the warnings plugin as those steps happen? It's just that kind of workflow and kind of like example, Jenkins file and that kind of stuff. Yeah, it would be a great addition. So, there was some items about that mentioned in the original proposal. So, if you're interested to know more information, you can find it here. But yeah, it's a proposal, which is draft and obviously you'll see what will be supported as a part of JSoc later. But yeah, you can see some deliverables there. And I believe that it was discussed what Casio wants to implement specifically. Or maybe not. Maybe it's not discussed today in details. But in such case, you should definitely go to the chat and bring up this question because it would be a great feedback to the project team so that they can decide what will be the answer of this question. Okay. So, let's just take it offline because yeah, definitely Casio has connectivity issues. So, anyway, thanks for this presentation because it's definitely a great demo and it provides a lot of information about what's being done in this project and everybody is welcome to participate. Casio. Okay. Oh, does the audio work for you now? Yes, I think it is. So, so everybody is leaving? No, some people left, but we had a discussion. And there is still open question from Chris which you could probably answer. How do you plan to implement that? Would it be automatic report tank or would users need to do it steps to get the checks reported? But that depends on, okay. So, but that depends on the, on the, how the consumer plugins implements our extension points. So, that's it. Yeah, have you already discussed it for code coverage, CPI or for one extension plugin? Yes, and what for the warnings plugins, just like I showed the PR, I'll open it by Uli and about the API just going to use a way I designed like I attached the results through around to the, I attached the results to the run through action. And so, during the build steps, all the plugins are able to access this action. And so that access, they can access the results and change some properties in their results. And we can retrieve the results and at the end of the job. And then we report it to the GitHub. Yeah, sorry. I was just, it's maybe a kind of low level Jenkins technical question regarding that design. I'm wondering if it's possible for a plugin, for example, warnings or whatever, is it possible for them to create an action and then another plugin like the GitHub check plugin to automatically notice that action has been created? Like, can it listen, kind of plug in, listen for actions being created on a run? Because I'm just wondering if there's like, yeah, if you can have kind of like a decoupling there where you don't have to, I don't know, it's just a bit simpler, I don't know, perhaps. Yeah, in principle, it's possible. I'm also not sure whether there is a good API for that right now. So you can always connect to a saveable listener and get notifications when the metadata gets saved. Yeah, let's just take a look at the current run listener implementation. So I guess here there is no step for action created. So, but if it's a use case, we could probably add one, maybe there are other APIs which support that. But on the low level, you can just connect to the saveable listener to capture this data if the action is persisted. Okay, thanks. KZ, what's the plan for this plugin? Like, it would just be providing extension points for other API plugins to report like the checks to GitHub or the checks API default would be doing some sort of reporting as well. Well, I can't repeat your question, I'm not quite on stand. Okay, so like the checks API plugin would be by default doing some reporting to GitHub or would it, okay, so like would it only be providing extension points or would it also be doing some default reporting? So what are the default reporting that you are planning to do? Yes, the defaults, the default parameters are like the started ads, the time when the job started ads and maybe the status, it will provide the defaults at a different stage of the job. So it provides the default like crew in progress and completed. And so some other things like the conclusions, if the consumer plugin didn't provide the conclusion, then we will get this conclusion from the jobs results and like the job canceled, well, it says the conclusion has canceled and if it fails and then we set the conclusion to be failed. So this is currently about the people's configuration. Okay, cool. Are there any other questions? If not, so, yeah, thanks a lot for the presentation and thanks to everyone who participated and it was an interesting discussion. We will post the recording on YouTube just today or tomorrow. We will try to clean up some features there while we are handling this network. But the video will be there and if you're interested to know more, please join the project channels. And I believe there will be a lot of interesting news there over the next few months. Great work, KZ. All the best for your coding period. Last one. Thanks, Al. I'll stop the recording.