 Hi everyone, I'm Koji. Today, I'm going to show you my GSOG project, Github Check API plugin for Jenkins, and my mentors are Wooly and the team. First, I want to show you our product of this project. First way, I release the general Check API plugin. We provide this to be prepared for similar concepts in different platforms like Github, Github, it bucket or some other platforms. And we also provide the implementation for Github, it's called Github Check plugin. And after that, you can consume our API to publish checks to Github, like this. And we have not released both plugins. We can just go to the plugin center and install our plugin, try it. After release of plugins, we consumed our API in the warnings plugin. Sorry, it should be warnings next generation plugin. And we have the following features like the calligate, there are red X and some green checks here that indicates the calligate. And you can see many issue status here. And you can also see many annotations for the new issues. Since our plugin has already been deployed to the set.jnkns.io, so you can just go to any plugin of Jenkins under the organization and on Github. So you can see it. For example, this is a very round request for our plugin. And if you go to the checks, you can see many analysis from the tools. And you can also see them along the code. So you can see the CPD warning. And if you take a look at the rule output, those are just parsed from the XML file from those tools, or CPD warnings. And the next is about the pipeline usage of the warnings plugin. And it's basically the same as the warnings plugin pipeline. And by we added a feature to skip the publishing checks, you just add this field and set it true. So you can have you if you don't want the checks, you can just skip those checks by adding this field. And here is the document about the warnings plugins pipeline usage. Let's see more here. And besides the warnings next generation plugin, we're also considering our API in the code coverage API plugin. And in this usage, we show you the coverage trend, and the coverage health score, and different kinds of coverages. And you can also use this feature, skip this feature in the pipeline, just the same as the warnings plugin. And you just need to add these features here. And you can also see a section in the configuration page. And like this. And you can just check this box if you want to skip the checks. And you can also directly use the pipeline and to publish your customized checks. For example, you just need to add this function in your pipeline script as the name, conclusion and summary. And then you will automatically publish this check for you. You may want to use this feature to indicate the stage of your build. For example, if some if some stage costs may time much time, you can you can use this feature to help you keep keep up with the what's going on in the build. And the next we also add the rerun request. So the users can just request the rerun for fail check directly on GitHub. And when the check failed on GitHub, the GitHub will just automatically add a rerun button here. So after you click it, we will we will schedule a build for you. And you can see the cost for the build is rerun request by me through the GitHub checks API. And this is still a feature. And this we haven't had merged this progress. Yes, because I'm still waiting for some dependencies updates for merging this. So and then the next part is I show you how to consume our API to create the checks. So because you may say this is very complete code here. And by this, that's because there are many so many options that you can configure for check. For the simplest for I just show you all the fields here. So it produces much code. But in the simplest usage, you may just need a name status details URL. It's very easy. And at last, you have to create a publisher. You just invoke the state factor method, and it will return a suitable publisher for you. If you are using a freestyle project, I will return a publisher for the freestyle project. If you are using a GitHub branch source plugin and GitHub branch source project, or just the GitHub organ folder project, we'll we'll also return a publisher for that. The next part is I show you how to create the actions. If you just want to create the actions and get up. And so when clicked, a request will be sent to GitHub app. In this case, the GitHub app is the Jenkins. And so you just need to and later implemented some logic to implement the action. And it can just make the Jenkins more convenient for the GitHub users. For example, I just if I want to add two buttons here, one is format, another one is report. I just need to create the details with actions. So here I just add two actions, a format and a report, and they will automatically add those two buttons for you. So later, you may want to implement those actions. And so first, you want when the users click that button, you receive a request from the from GitHub. And there is a section in the payload, the request action and the field is identifier. So you can if you want to handle this request, you just want just need to extend the even a subscriber. It's provided by the GitHub plugin, you extend it and subscribe to the Chikran event, implement the even handling logic, implement those logic in the event method. So you can just create and you can just implement the actions for the users. If you want to see more examples, you can just go to the GitHub plugin. There are many examples like the push, push event subscriber and pin event subscriber. And you can also see our subscriber for the wrong request. That's how we implement here. So in the demo part, first, since our plugin has already been installed on stya.genkins.io, so if we go to the plugins folder, and if we some, see some plugins build, and we go to the GitHub branch. Yes, here. If you go to a check and you'll see those checks for this progress. Yeah, it seems a very good progress without any issues. And if you go to this, if you click this thing, it will just direct me to the to the ocean view of this view. And the next part I want to show you is a real request. So the page for the rerun. Okay, so here I have a field request field check. So if I click this rerun button here, I can have, well, give you a feedback, we have successfully requested the Jenkins rerun. And and since I'm using SME forward delivery, so you can we'll just deliver the request to our gene to my Jenkins. You can see here in the log, it says receive the rerun request through GitHub checks API. And the next message is, it says is schedule the rerun for his job. And it's requested by me. And this username is parsed from the request payload. So it's GitHub user ID. And if you go to, if you go to the Jenkins, so go to this view, you'll see the cost is because we want is a rerun request by me through the GitHub checks API. And another part besides the request, I want to also show you the pipeline support. This is a pipeline generator. So I add these fields here. Since some fields in the GitHub supports markdown for some fields, I use it markdown syntax here. So I generate a pipeline script. And I copy this. So for a quick demo, I just want to replay use a replay feature. I'll just copy this, this there and I click run. So if I go to the page for this, you can see here, still queue refresh this page. Yeah, you can succeed 36 ago. And you can also click this link here. Yeah, also need you to the URL. This need us to the set up Jenkins.io because I said, we are here. So so this pretty much from a site. And if any questions, you can just ask them. And we also would like to have any suggestions from you. Thank you. If you want to see more details about this project, one week ago, there was Jenkins online meetup where we were specifically talking about the GitHub app identification and checks API integration. So there is a bit more details there. And yeah, thanks a lot for the presentation. Again, if you have questions, please use Kone. And meanwhile, maybe all your team would like to share some feedback. Yeah, I can thank you first of all for this wonderful enhancement in Jenkins. And we already have now two plugins that are using this extension. And I hope a lot of different reporting plugins will come again. So for instance, we can pit mutation coverage show them, or we can use the test results published using this approach. I'm really looking forward on different plugins implementing this new API. And maybe one extension, it works not only for GitHub branch sources. Now it works also for freestyle builds and for normal pipelines as well. So thank you. Yeah. Thanks, Casey. It was really good. I think given the warnings in G and it's on ci.jegas.io, it's already getting a lot of adoption probably faster than most t-stop projects in the past. So I think it's a really good achievement. As one of the grateful users of your contribution to ci.jegas.io, thanks very much, Casey. I've loved what you did with this. It's made my life better. Thank you. Thank you. And if you will keep evolving that, but even the first integration steps have been a really good advantage. And thanks to the team for also doing the groundwork to integrate static analysis in our default pipelines. I mean, we had find bugs, spot bugs before, but now we have basically all checks available. So something like eight different tools. We can keep expanding that. Yeah. I believe from the future, we will be able to add more analytics features as a part of the engine. Yeah. One more thing. The rerun feature seems to be very, very good because currently you can't sometimes rerun builds. You have to push an empty commit. So is that is that the feature that you need to be an admin or an owner of the repository to be able to trigger a rerun or anyone can trigger a rerun? Yes. Unfortunately, we've got to add the ability to get ops. We haven't done that yet. Or chat ops is what we need. But you're right, Slayton. It's too inconvenient right now on ci.jankins.io. That's coming. Yeah. For CI Jenkins, we have a plugin, GitHub comment plugin, which re-triggers the build if you have right permissions. Sounds good to me. We haven't integrated it to CI Jenkins yet, but if you're interested, you can find this plugin in the plugin installation manager. Okay. Are we sure that we definitely need that to re-trigger? I'm not sure exactly what the permission is, but I would expect that if you're the author, you can probably rerun it. Does anyone know? Something we can test offline with the meeting. Yeah. I'm pretty sure. I'm pretty sure authors can do it, but we'll figure it out. Thank you. So at the last, I just want to say thanks to all my mentors, William team. I received a lot of help from you and although there's some time gap, but I can always receive many in-time reply and many techniques and the skills you taught me, it's a fantastic summer. And those skills, I can migrate them to some other projects, maybe just outside Jenkins as well. And I want to also thanks to the people from the whole community. This is a fantastic community, very helpful and friendly. And then also thanks to you to introduce me to the open source world. And just thanks.