 Thanks all for joining this meeting. Thanks to everyone who watches it online. Today, we have a special discussion about GitHub checks API project. We have for Google Summer of Code this year. Do you see my screen? Yep. Oh, cool. So yeah, we have a project ID which basically is related to adding support of checks API to Jenkins and specifically being able to submit information for warnings and G-plugin and for code coverage API and maybe for other plugins related to static analysis and just various kinds of verification because this is where we could get a lot of benefits from checks API in Jenkins. And we already got a few proposals from students for this project, which we are reviewing. So today, we just have an opportunity to do a Q&A and maybe to do some sync up with regards of what needs to be done, especially if there are multiple students interested to work. So we could just use this time to see whether we could parallelize that or how we could adjust the scope. Since we have multiple people on the call and I guess not everybody knows everyone, we could do quick introductions, especially for some need sliding and those students who watch it. Yeah, I could begin. Oh, okay. Yeah. Sorry to interrupt. Yeah, that's fine. Yeah, so I'm Sladen. I've been working with Jenkins for the past, I mean, five months, I guess. So with the Community Bridge project, I was involved with Tim and Joseph in building the JSON schema generator for the JCASC. So I have a bit of knowledge about the Jenkins ecosystem. I have been contributing in various areas like document migration, a bit of plugin, warnings plugin, maybe GitHub API and stuff. So yeah. So this time I plan to do my, I plan to apply at least to Google somewhere of code with Jenkins. I have submitted, I guess, three proposals in different areas, one of them. And my favorite is the GitHub checks API. So yeah, that's about it from my introduction. Since we started from students, Sumit, would you like to introduce yourself? Hi, my name is Sumit. I'm also a prospective GSoc student, but my, like the proposal that I'm working on right now is the external fingerprint storage proposal. So maybe you can think of me as an observer on this meeting. Thanks for introduction. And maybe there could be still some overlap between projects, who knows. I hope that. Yeah, let's see. So anyone else? Maybe you, Uli, since you're not here yet? Yeah. Is there no student anymore? Okay. I thought that there would be more, but yeah, let's hope that we'll watch some line. So my name is Uli. I'm the author of the warnings plugin. And yeah, I think some of the requirements are coming from my plugin. That's the reason we want to have this project. So I talked with a lot of users of my plugins and what they wish is to have some information from GitHub, from the Jenkins job in GitHub. And that's the reason we started this project. Jeff. Hi, my name is Jeff. I'm a contributor to Open Source. This is my third year in involvement in GSoc. I maintain a couple of plugins and I'm also the author of a plugin that provides build information via the GitHub status, a commit status API, which is deprecated and also to various other dashboards. So it's kind of in this area. So I'm interested in just monitoring in general and doing what I can to help move it forward. Plus, Jeff was a mentor in the code coverage API project. So he has insights about how it's organized and it could be also helpful. Okay, so we have Ke$ha on the call. Would you like to introduce yourself? Presently, I cannot really see a shot when I'm screen sharing. Okay, sorry for the late. I'm Ke$ha showing a commit Ke$ha. I came from China and I'm interested in this project. I've tried to wrote a project of concept and I posted in our Twitter channel. And I have contributed to the Warnings Next Generation plugin before and also the GitHub API for Java. And I want to participate in this project for this summer. Thank you. Thank you for introduction. And we also have Rick on the call. Yeah, we're commuters. Okay. Hello, I'm Rick. I'm a contributor of Jenkins Community. I also maintain several plugins. This is my second year to participate in the GSOC. And currently I'm focused on the custom Jenkins Bureau of Service proposal. Hope I can help the community. And that's all, thank you. Thank you. My name is Alec. I'm one of GSOC Orchard means. I started participating in GSOC in 2016 when we did the first Google Summer of Code Jenkins. And I'm really proud of this program and I'm happy to contribute however I can. And I'm a very big fan of GitHub checks API. So if you get its support for Jenkins, it would be awesome. And I will do my best to contribute and to share expertise when I can. Okay, yeah. So we've got quite a number of people there and thanks all for the interest. I think we could spend some time, maybe only you as a lead member would like to just summarize the project and provide some overview if you would like. And then we could go to Koini. So I'm just looking if I can share my screen. Is this? Yeah, I stopped sharing. So you should be able to share yours. Never tried it. Okay, now is it sharing now? No. Yes, it is. Yeah, yeah. Okay, so I think the proposal is best described if you have a look at a typical pull request of Jenkins or one of the plug-ins. This is one of Jenkins plug-ins. And this is a typical pull request where we have a lot of commits here and a lot of checks. And what we have here is some boxes in this pull request which are from other tools. This box here, for instance, is from Codesy. Codesy is online service where I can check my source code with CheckStyle, PMD and several other tools. And they post some messages for each pull request here, for each line I'm modifying. For instance, here that I have done some code modifications which are not okay with regard to the rules that are configured by CheckStyle and PMD. What we do in Jenkins, so I need to scroll to the bottom here. We have here are the jobs which are running after the pull request has been committed. And the last line, or this line here is showing that Jenkins is building the pull request and this is the only message what Jenkins is showing currently. So in order to see why this commit cannot be built, I need to click on the details and then Jenkins is opening its user interface. The idea for my plug-in users is that it would be much better if we run the Jenkins build and then push these notifications in this style here in form of the pull request. So everybody sees which line has a new warning, et cetera. So this is, I think the main idea behind the proposal from the user perspective, it would be nice to have warnings for each pull request shown directly in the pull request and not only in Jenkins user interface. And if we extend this approach a little bit more, I think it makes sense to also show new test failures, a code coverage increase or decrease and things like that. Everything what is actually monitored in Jenkins would make sense to be presented in the pull request here. So nobody needs to open the web interface of Jenkins. And if we think it a little bit more, maybe in a couple of years, Jenkins has no user interface at all and it makes sense to just get the data from Jenkins and present it somewhere else. And one thing would be to show it here in the GitHub pull request. And it's not a miracle that there are already some projects which have no web interface. For example, BOT-CI in some sense, or Jenkins Cloud Run, and if you take something new and experimental. So it could be definitely done. The Jenkins can operate in this mode. So this is, I think the few of the proposal from my requirements few. So what needs to be done on the technical side to implement this? Actually, I don't know how to do it. So I know there is the API in GitHub, but I think the students are already much deeper in that part as I am. So I can't say much to the API itself in GitHub and what needs to be done on the tank inside here. So I think for me, it's okay if it has somebody, some questions regarding the requirements here. I have a question about the current status API. And I want to know what's your way to create this status API? And because that's so many plugins can create these status like the GitHub plugin and some other plugins. I want to know what's the current way to create this. You mean this thing here below? Yes, yes, yes. Actually, I don't know it's automatically generated for me. I'm just using the default Jenkins file. So I don't know if someone knows how it is generated. So the one that says this commit cannot be built, that's via the GitHub status API, which is deprecated. The GitHub actions, I believe that's the newer API that they'd like us to move to. And it requires having a GitHub application where the one with the little Jenkins had continuous integration, Jenkins branch just requires that Jenkins have the ability to write to a REST API. So that's again, so the continuous integration, that's the one that GitHub says is deprecated and the others are the new style that we want to move to. Does that make sense? And it doesn't really answer your question. I don't actually know how to write to the GitHub actions API because I've never done it. I could provide some insights on that. Actually, if you kind of write an application and from the register it to the GitHub applications, you go to the developer settings and actually create an app, GitHub actually lets you post certain events to the GitHub page. So as soon as you run that check or you run that application, GitHub automatically kind of takes events from your app and posts them on you. So there are different kinds of events like on create, on complete, in progress and stuff. So as soon as you create, as soon as the pull request receives its first event, GitHub sends out the create webhook to all of the apps that are subscribed to the repository. So if you create an app and you subscribe it to the repository, GitHub sends out the create webhook and your application can actually catch that webhook and run a status check. So that's what most of the actions or apps do. They capture the create webhook, run the CI check, mark the status in progress and when it's completed it posts the warnings and ends the check. So that's how the current flow of the GitHub app works. Kezi, were you asking about how the GitHub status notification works currently in Jenkins or was it about the GitHub app? I tried to create these status using the GitHub API but I'm not sure many other plugins can also create these status. So I don't know what's a normal usage to create these status. So I just sent a link on the chat. So I think each one extends the GitHub notification strategy class. So it's an extension point and then you can send a notification through that. There's also the GitHub notification context, which is where, so there's the default message in the GitHub notification context, which is where it decides what it's going to send depending on the build result. So there's inside the messages file there's like 10 different texts that it will send based on how it was based on a result. And so yeah, different plugins can implement that strategy. And I think there's also other plugins which just do it themselves as well to send ad hoc notification messages. Yeah, it's not exactly the state of the art. Also, there are several libraries for GitHub API and Jenkins uses GitHub API slash GitHub API. It's a project which was originally created by Corsica and now thanks to team it supports a GitHub of certification and other components. And I forgot to introduce team in the beginning, sorry. So yeah, if you would like to introduce yourself it would be great. Sure. Hi, I'm Tim, at least seem to introduce me. I use GitHub a lot. I'm a maintainer of a few plugins in Jenkins Slack. Azure Key Vault configuration is code and Jenkins Core maintainer as well. You can fairly large Jenkins instance in my company that we use but also quite a lot of Azure DevOps as well. So I see quite a few things there that would be quite useful in Jenkins. The checks API and just being able to see summaries in your pull request and test results and rerunning sort of stuff. And this would be a good start to make it easier to implement those features. I've looked at implementing this before but it was basically blocked for a very long time because GitHub API project wasn't released for almost a year. It got stuck in transition between Corsica and others. And then finally, Liam is now taken over there. So it's moving at a much faster pace. And because of that, I was able to get the GitHub app authentication working for the GitHub branch source plugin. So I think that should be quite useful for this as you shouldn't really have to worry about any authentication. It should be hooked into the Jenkins credentials mechanism pretty easily and that should be released very soon, I hope. Yeah, I hope it will be released next week. I guess now it's just a matter of clicking the release button because there is so much feedback from users who built the plugin on their own and confirmed that it works. If there's someone who works at GitHub who's missed like three times on the pull request. Well, everybody has their own interests. And yeah, like 10 plus companies using it in production, I think. Yeah. Yeah, we're using it with like 15 apps for like an organization that has about 1,500 repositories. Okay, so thanks a lot for overview and for some examples. Do we want to discuss the project details a bit more or should we go to Koenig? Sure, probably not. Yeah, this is my screen. Does anybody have more details? Meaning, I feel like part of the process of developing the project is to maybe develop the details. Okay, then we can adjust the depth during Koenig. So I think we could just proceed. So are there any questions? Slaughton, you're mostly muted. Yeah, actually I wanted to ask one question. I had a question regarding the code coverage API plan. So the code coverage API plugin, so how do we want the code coverage to be displayed? Because there are a few ways that currently, I think code curve displays reports, but code, I think there is a plugin existing that just displays the coverage personality. So how do we want to proceed with that? Do we want, because I don't think the checks API supports reporting coverage reports, but the GitHub pull request review comments does allow you to post reports. So how do we want to proceed that we want to replace reports or just the percentage of code coverage? For me, one of the interesting case cases we had in previous systems. So it was actually a team foundation server long before it went online. So we were getting warnings in our change requests about code coverage issues, particularly about the parts of the new code which is not covered by tests. And if it was displayed via checks API, you could just put information to the lines and say that, hey, this block is not covered. Do something about that. It would be the first obvious case for me. Mm-hmm. Okay, yeah, yeah. I think I can, I shared a link in the, I don't know whether it's in the chat. Can I just speak to it here? Yeah, you can edit to this doc. Yeah, just hit me. I think what I can show you is how another tool in GitHub is showing the code coverage, which I'm also using. Okay, just show it. Okay, so, this is another prerequest of my plug-in. And here, what I'm using is code coverage or a code cuff, this tool, I don't know how I want to call it. And this tool is computing the code coverage from the change. And yeah, this is not really interesting because this is just a dependency that changed. But normally here you see which kind of coverage you have changed in the positive or in the negative way. And then you see some difference and you see, for instance, what has detailed change. So I think we can do something similar from the code coverage API. Does this one? Delta report. This one publish it to another service, like a code cuff, the external service. Yeah, this is an external service. I'm pushing the, I think Chacoco results to their server and they are computing a Delta. And this Delta they are showing here in the pull request. And you can, normally you can put some thresholds where you can say, okay, you should not go lower with a percentage than otherwise the pull request will fail. Or the tech will affect the pull request. It's interesting. It almost feels like it would be great if this solution was extendable so that it could maybe publish information from different places. Cause you know, some people probably would want to use that code cuff service. Some people might not. So maybe there'd be some different options or different ways to extend it. Yeah. I guess the code coverage API plugin does support some report generation. I'm not. I did some research on it, but I guess it supports two or three, Chacoco and Colbertura, if I'm not wrong. Yeah, it supports, yeah. Yeah. Yeah. Supports Chacoco, it supports Cabertura. So the plugin Jeff maintained. I'm not sure Jeff, do you maintain Cabertura plugin now? Yeah, yeah. I think it maybe supports LLVM as well. It does. It was released. Plus there were some experiments with hardware code coverage plugins. But it hasn't happened yet. I'm not sure what other companies do, but in practice what I've seen is that almost all of the coverage that we gather gets converted to the Colbertura. Cause like I've done a lot in Node.js and we're doing Golang right now and all of those and even Python. There's ways to convert it to Colbertura and then publish that. So it tends to be kind of a common format. Yes, at least in my experience. We used such approach a lot and actually there is a lot of converters until the very recent time it wasn't possible to publish, for example, coverage for C++ code in Jenkins without conversion through Colbertura format. There is a project called GCOVER. Also we were publishing hardware code coverage using Colbertura reports again. But it's still a partial misuse because Colbertura format is far from being video though it provides basic information. Yeah, and it's also pretty Java centric. So you're kind of like trying to fit results from whatever you are into sort of a Java framework. Sometimes the results are funny but we just care mostly about line coverage and so that's pretty easy to get from that. Yeah, so probably the code coverage API plugin could, I believe it does have some more extension points. So they do publish some of the reports. So maybe the GitHub checks API plugin could make use of those reports to, I mean, pass those reports and probably generate some sort of reports that are much more useful to be displayed in GitHub pull request. So I guess I've posted a link on the document. Maybe this is a parser that currently exists. I'm not sure if some of the heavy lifting can be done by this, but yeah, this is what I was researching and I mentioned in my proposal as well too. Yeah, that's just my two cents on it. I think one plug-in, which should also report something is a JUnit plug-in. So if someone in a pull request fails a test, it would be very helpful if the test failure would also shown in the pull request. So currently Jenkins says, yeah, it failed and then I need to go to Jenkins to see where it failed and it would be much better if we also have the JUnit plug-in report at least the failures in the pull request. Or would that make for you a sense as well? I think that would be useful in our experience because a lot of people that I work with, one of the things they don't like about Jenkins is having to click through the link and go figure out what failed. And so the more information that we could have on the pull request page, the happier people would be. Yeah, I agree with it. Just one comment for students. Yeah, there are many opportunities. There is no need to do everything in three months. And if you wish the work could be paralyzed, but it's yet to be discussed and just make sure your proposal is something which is implementable from your point of view. And then we can discuss many of these options. Yeah, I saw many the potential milestone in the project proposal of the Chex API. And should we include all of those milestones in our project this summer? You mean these milestones, right? Yes, yes, especially the general API for pull request for the other platforms, the third one. And I don't know whether this is feasible because I'm not so familiar with Keyboard Lab or PIDPocket. And I don't know whether they have some mechanisms like the Chex. Not always, I guess the keyword here is possible. So what do we do in Jenkins? We offer wide open project ideas so that students could research them, explore the area and come up with their proposals. And they get a lot of freedom of what they can propose. We start from there. So Uliup, please correct me if I'm wrong but I think that all items here are just examples of what could be done. These are actually examples. I think it is a good project which can be done very incrementally. So we can start with a simple check that prints some Hello World from Jenkins and then maybe a warning. And then I think it's up to the student in which direction we are going. And it's also really hard to decide now which are the milestones. So I have wrote some deliverables in my proposal. And so I'm not sure whether those can be implemented or achieved later. And so these deliverables can be discussed and changed later. So what you do now, you do a project proposal and we totally understand that we cannot commit to the scope right now because their proposal may change, the environment may change and there may be obstacles to discover. So it's pretty much like in any software project. And right now, yeah, you work on the proposal. We want it to be feasible, but still there may be a lot of changes during the project itself. For example, during community bonding, we usually ask project teams to work on a mini design based on my original proposal so that you review your proposal together with mentors, see what could be done in a different way, what needs to be done, what could be excluded, what would be the order. So you would work the project together and basically start working after that and the final project plan may differ from the original proposal. So we don't consider students to be committed to, fully committed to what is listed in the deliverables. Of course, we want it to be somehow aligned. So don't expect the situation when you come get accepted and then people say that you do completely different project, no, it's not going to happen. It will be a discussion between teams. And we want to have proposal along these lines. But if something changes, it happens. And basically our approach is, as long as mentors are happy with the result, we are happy as a recognition. Sometimes there are really interesting results and deviations. So for example, when we were working with Shengyu together with Jeff in 2018, I believe the original scope of the project was completed in mid June or something like that. And then we were exploring slightly different areas. The overall, it was really successful project. But yeah, such things happen. And please don't be afraid about that. But still think what you would like to work on and what would be your personal interests and priorities. So if you're concerned about this item, if you don't really want to work on that, you can find something else or you could just put it to the tentative area for the future discussion. I'm not sure. What do others think about this general API? I mean, I'm always a fan of having APIs that can be used by other plugins. I think that maybe the mentors or the community could help flesh out at least what the interface would look like. That's general and maybe we only implemented for GitHub but the interface is defined so somebody can add the others later. Will you team? Yeah, that's a good idea, I think. Yeah. I have a demo to present. Can I have like five minutes of the call to maybe show some demo? Why not? If there is no other questions, we could definitely spend some time on that. Are there any questions? Especially from a player, if not, okay. Let's do a demo. Yep, can I share my screen? Yes, please go ahead. Yep, just let me know when my screen is visible. Yeah, it's visible. Okay. So what I did was in my proof of concept that I wrote for the Jenkins, for the plugin, what I did was just a, so I think the warnings plugin generates a sort of, it generates a warnings report. So I just took a basic warning report that's generated. Just give me a second. Just find it out, hold on a second, yeah. So I just took a basic warning report that's a static warning report and on the basis of that report, since obviously there is no dynamism involved, I'm not making any call to the Jenkins report or something, warnings plugin. So what I did was, this was the kind of report that was generated. So it can show you the line number, the file name, the line start, line end, and stuff. And I wrote a Springboard application that is basically registered as a GitHub app currently. So this GitHub application does what, it passes the warning report and for whatever pull request that you generate, whatever pull request that you generate, it shows you what kind of warnings have been generated. So if I take a look at some of the warnings that have been generated here, so I'll show you an example. So if you look at the warnings report here, it's just a static warning report, so it doesn't make sense though. It can show you the message, so it may fail to clean up Java input stream or return value of report, okay? So you get the gist of it. So these are the kind of warnings that have been generated. So currently there are only three warnings generated. So what I did was, I wrote up the app and registered it with GitHub, so GitHub runs it. So if I can show you a demo, so this is just a test file that I've written. It's just copy pasted from one of the freely available repositories, so it just doesn't ignore what's written in it. But what is important here is, so I've registered the app on a particular repository. So if you have a look, I have the sandbox repository. So this is just a blank repository. And what I will do is I will push a pull request to this. So I'm gonna push this to my, just hold on a second, so I'm gonna push it to my, just five, six. Yeah, so this should probably open up pull request here. Just give me a second. Not happening for some reason. Yeah, so this should, what is wrong? Okay, nothing gets pushed to the, oh, sorry, my bad, not committed. This will probably allow me to, yeah, open a pull request. So this is probably where the, so my app is running. So what happens is it receives a commit and if you have a look here, it actually, just give me a second. Send in the checks from here. Yeah, so if you have a look at the checks plugin that kind of displays this morning, so if I have a look at some of the pull requests here, it actually successfully displays some of it. So if you look at the earlier pull request that I opened, so it publishes it like this. So you have the warnings in the line. So whatever bot we have or whatever app we write later for the warnings plugin, it will kind of display whatever warnings we have after invoking the, after getting the report of the file that we have generated. So whatever file we pass into the warnings plugin, it probably has a, I mean, it probably puts it on to the pull request comment. And the other way that we could probably do it is using the checks, the checks UI. So the checks UI is this way. So if whatever warnings we've opened up here, they show up like this. So we could either take that approach or we could either take this approach that it just displays the warnings on the checks plugin or it goes ahead and displays the warnings onto the conversation. Now the conversation could become very cluttered because of this, because there might be 20, 30, 40, 50 warnings. GitHub checks API limits it to currently 50 for a time. But yeah, so this could probably be one way of displaying the pull request warning. So yeah, this was the demo that I wrote. This was a proof of concept that I wrote. So this could be, I think Tim has worked on the authentication of it. So that could probably be reused. And since I've already used the GitHub, I've not made use of the GitHub API and I've written some of the functions on my own. Yeah, that certainly could be reusable. But yeah, I just wanted to kind of display the proof of concept since we plan to display warnings on the pull request. So this kind of makes use of the warnings report that are generated. So the warnings, the plugin could develop, could be extended, could have an extension point. And this could be connected to that. So currently it's just a static warning. But yeah, this would probably be, I think step one or just a basic proof of concept. Yeah, that's about it. So yeah, that's my item. Thanks for the demo. So yeah, maybe one question we could discuss today. So here we have two proposals. And we had such cases before. So when there are two good proposals, there are actually multiple ways how to resolve for this situation. Hi, Preeti. Yeah, so there are multiple ways. One way, basically a kind of competition so that whatever best possible proposal wins. But it's not the only way. Because it's an open source project. We deliberately try to keep as much information as possible in the public. And we encourage students to collaborate with each other. And for example, if you're interested to work together and see whether it could be somehow the conflicted. So that we could have two proposals which are more, which operate in the same area, but can be delivered separately. Then it would be also possible. So just something to think about. And if you want to discuss it more, we have time. And yeah, basically it's full projects. If you are concerned about a competition or whatever, see whether you could convert the competition to collaboration. Yeah, it would be up for it. Collaboration sounds like a really cool idea. I have no issues in setting up. Maybe in collaboration we could work in parallel for the project. Maybe one could focus on maybe some other set of plug-ins like code coverage or something like that. And one could focus on the warnings and stuff. Sounds like a cool idea. I would definitely focus on that. It might be possible. So obviously it depends on the number of slots we have on other applications, et cetera. But yeah, we encourage students to explore these options if you're interested. And yeah, highlight students. So we could probably do it as mentors. But we can just provide guidance. We won't be doing this, the conflicting for yourself. Because if you expect to work together in the future, it's better to see whether it's possible now. But yeah, technically, these options are possible. So is that left up to the mentors to decide or to the students? Any comments, insights, maybe some hints from others? No idea. It seems like it's both, right? It's the mentors agreeing that there's enough work for two people to work on it. And I guess also the students convincing us that there's enough work to have two projects, right? Because it's like one GOC project. It's three months of coding. So if we could collaborate and get six months of coding in three months, then it's possible. Yeah, it's some additional requirements to projects. But technically it's possible. And there are cases when there was successful collaboration. We didn't have such example in our organization so far. We had students closely collaborating with each other. But because, for example, in areas like JCASC, where there was overlap, but you didn't have cases for a single project, 38%. But other organizations did have them. And they say that it actually works pretty well. Do we have two students or three interested in this project? So we received two project proposals now. But a number of students in the end will be on the 31st of March. So we have a pretty Sharma on the call. We have Sumit. Maybe Sumit watched the discussion and decided, hey, now I want to work on a Chex API, who knows. And maybe other students will submit. Let's see. So we do know the number. And yeah, they multiple potential situations. But we will figure out it in a proposal processing. So from an org standpoint, if there was a possibility of collaboration, would we just submit the single collaborative project and not the two individual ones? Or would we submit all three? All proposals should be submitted individually. And all proposals should be deliverable separately. And they should be measurable separately. Why it's important? Because life happens. And especially this year, with all this incident in the around, nobody knows what's going to happen tomorrow, not speaking about the GSOC time frame. So that's why there is strong requirement from Google that projects could be delivered separately. Obviously, there might be some conditional, et cetera. But technically, it might be possible. But each proposal should be submitted separately. And it should be related separately. OK. Sorry for this detour to the project and organization side. Do we have any questions about the technical side of these projects, about the implementation, about areas to explore, anything? I want to talk about my implementation. OK. Can you show the workflow graph in my proposal? Oh, yeah. I can show it for you. OK. This one? Yeah, yes, yes. Thank you. I have implemented most of the workers in the listeners. And after the GitHub has sent a request for our checks round, and my subscriber will subscribe the event. And it contains a message query. So later, when the listener was triggered, like by Jenkins Brown, triggered by Uninitialized, as you can see on the graph, it will request the checks to event from the message query in the event subscriber. And it will then have implemented some extension points. And other plugins can extend these extension points and to provide the information, like summaries, conclusions, and I'll gather those informations, just like searching in the extension list, and get all these plugins, informations, and then create the check rounds. And as you can see later, I will do almost the same thing. On start or on complete. And I just have a problem with my implementation for now, because the event is independent from the Jenkins Brown. So there is a situation that maybe the Jenkins Brown has started, but we haven't received the GitHub event. So for this situation, we can't create those created rounds. Yes, I don't know how to handle this situation. I don't know whether you have understand me. I kind of understand, but I think it'd be nice if you could give an example of when that happens and what the events are, just to tie it, just to help focus it more. I have wrote a section about the flaws on my proposal. I think it's a bit later. Can you show us? Can you help me, Oleg? Yeah, just a little. Yes, it's up a little. In the front, the last one, the previous one. This one? The previous one, the previous one. The previous one. Yes, I am a bit lost. Should I go up or down? Go up, go up, go up, go up. Yes, yes, the flaws. Oh, sorry. Yes, I don't know whether you have read mine. Do you mean that the chick suite hasn't been created on the GitHub side yet? Yes, yes. We have to receive the created request, which contains information for the created check-around, like the ID, so we can later update this check-around using the ID from GitHub. Or we can't create any check-arounds. So that's my current problem. Right. Right, we need more time to look into it. On what the best way? Yeah, I started reviewing the proposal, but I didn't touch the checks API workflow part. I think that we can define it later. But if you need feedback now, I will try to take a look over the weekend. Maybe I could later provide an example about this if we can discuss later if you can understand for now. Is there a way that we can start a chop in Jenkins from the GitHub API? Yes, just looking at the suite here. It says that by default it will create one for you, but you can create your own as well. But normally it creates check-arounds. Normally when you open a pull request, it will automatically create a check-suit and it will ask you for some check-arounds. So you just need to create check-arounds. Yeah, it does also say that you can create your own one as well. Yes, yes. Would that help? I think yes, that could help. I haven't tried this approach. I can try it later. Yeah. Actually that check-arounds is probably the check-suit that the pull request passes could be is very, very useful in actually posting back because that check-suit event basically sets up your entire pipeline. So that's the first event you receive as soon as you open a pull request. So moment you hit the pull request, bang, you get a check-suit and you can actually on the basis of that check-suit start your entire pipeline. So I guess Tim has made that part. I think Jenkins as a GitHub app has already been implemented, right Tim? It's just the authentication. It's just the only bit that is implemented is getting the bearer token that you need to pass to the API. Okay, so yeah, if that's possible because if Jenkins as a GitHub app is possible then it makes this part very, very simple because then the warnings plugin and the code coverage API plugin just need extension because the app will generate a token for every organization or every that's enabled in. So yeah, it makes much, much easier if Jenkins as an app gets delivered quite easily. I don't know if that's a prerequisite for this project, but yeah, if that's there then it makes the project a lot easier. One comment, we slightly go over time and that is another meeting which should be happening now. So my proposal would be to take through the discussion offline and if potential mentors could take a look at this proposal and at the proposal by sliding and if other proposals are submitted your feedback will be appreciated and we can also continue this discussion in chat. So yeah, I believe that we need to release the Zoom account. Yeah, again, thanks everyone and I will make sure to post the video within a couple of hours. So once it gets processed by Zoom so that everybody can process it. Yep, plus one. So thanks all and have a great weekend. Thanks everyone for taking really appreciate it.