 Repositories. So here, this is a sandbox repository I created for for tasting our checks plugin. And so the next, I think we should take a look at the class architecture. So it's here. And so first, we have to subscribe the event from GitHub. So here, this subscriber is provided the green one is is provided by the GitHub plugin. And we just to extend this subscriber this class. And then we can, you know, kind of subscribe the event from GitHub. And so, so the next thing we have to do besides subscribe the event from GitHub, we have to listen to the Jenkins jobs. So here, we have this job listener, extend the crew listener and also the wrong listeners. So we can do different jobs, different take different actions like create a check wrong when when the wrong listener triggers the on start, and we can, you know, like complete the check wrong. And when the job job is incomplete. So and the extension point that provided now is this check wrong result. And this kind is an is an abstract class. So I defined some method like the get name, get output and get annotations. So if other plugins implemented this class, I can use this method to get the the informations from from from those customers. So I think I'll start my demo. So that would be clear. Okay, so this is a subscriber. And here we have the applicable method. So it decide whether this, whether this subscriber is is applicable for the current project. And the events we have to provide the GitHub events, you want to subscribe here, we subscribe the installation repository event, and the check wrong and checks, which is here is installation repository event. And you see the payload here is added. It's because I instilled I instilled the app on my on my repository just now, you can see the the the repository is sandbox. And this this this ID is the installation ID, we have to use this to authenticate design, and then repository in order to, you know, in order to use the API is to access API. So here I'm going to deliver this pale. So here. So here we can receive this event, the install in installation repository event. And the app we update update the installation is basically we map the installation ID to we map the repository name to the installation, installation ID, because later when we are handling the Jenkins jobs, we only know the repository name of the of the job, we don't know the installation ID. So we have to so I built I made a map here. So if so, so I show you the check run I made yesterday. And here is is it is it. And so can you see it? Can you see it? So the the name is default Jenkins run. This is because I have, I've provided default check run and the name, the name is default Jenkins run. So you can see here shows the default Jenkins run. But I haven't provided other things like output, or any annotations. So there's nothing here. So if we trigger the build again, some problems with my docker. Oh, I don't know what's the problem with, with my Jenkins instance here now. But I think we can still keep going up here. Because he has trigger the breakpoint. So here is initialize. So when initializing the job, we just, you know, create a new check run. And here we can, you know, like retrieve the source user SCM API. And here we retrieve the head of the of the current revision. So if the head is a progress, we can get the repository for a name. And you can see the full name is just accurate is a repository in my account. And the headshot. Okay, this takes a little longer. Oh, yes, because, yeah, yes, because I didn't open my local network. I can't do it now because my school network doesn't allow me to do that. So if I open that, I will be drop off the meeting. So I just show you, I just keep. So the headshot is, you will give you the headshot of the current revision, which is now, and now the this, this progress. And it should be one AC eight. And if we keep going there is installation ID, we can retrieve the installation ID from, from the, from the map we created earlier. So next we get the token, it's this token allow us to access a GitHub API. And then we use that. And here is how we retrieve from informations from the consumers. We, you know, just iterating all the consumers here, that by invoking the all method, and we create a check around here. So, so we check around. Okay. So here this method, currently, currently, I just use a patch client to create a check around. And here I, this is a, here is a payload. This are some headers. And in the headers, we have to bear the token. Here is a, is a body. So the name is a source, get name. And it's just like the default default check around source I provided here. You know, like return the default. Chicks. So here's a headshot. And we set its status into Q. And here we send this way, send this post to GitHub. And you will create a new check around on GitHub. And so the next thing, next thing, when the job has started, almost the same, except here, we just because, because back, back there, we have added all the created check arounds and to the attached to all the sources to our, our Jenkins run. So here I add actions. So later when the on started is triggered, almost everything is almost the same, except here, we just instead of creating new check arounds, we just, you know, get actions from the run. And then we update this check arounds we created earlier. So here, here also. Also, I just, I just simply set the status to in progress. And here is the states started at and this, and this time for this, for this job. Also, I send this, send this payload to GitHub, it will update the check arounds. So the next thing is incomplete. Also, like the on start, also like on start here, is just will be complete. So, you know, when we, so here we almost the same, like the updating the check around, we here complete the check around. And also some payloads, just a conclusion is success. And the status is completed, completed at. So here we send this payload to GitHub, it will eventually become like this. Oh, the same city created started 32 minutes, seconds ago. So this is this check rise were created just now. So, okay. So that's basically it. Yeah, that's the how the prototype currently works. Okay, thank you. It's really nice. Thanks. It's really good. So currently, the biggest, the biggest problem you can see here is that, you know, instead of we provide this statically, we have to retrieve the names, the status, and also when completing the job, we have to get the conclusion from the consumers. And we have to receive all these things. And we have to retrieve the, the, the, the informations from consumers about this, the output, you know, like title, summaries, tags and patience for, for lines of a code. And the above things we can provide because the name, when the users, when the consumers are defined their extension, they extend the extension point that to, you know, implement the return name. And so name is, is in our control. So the headshot also. And all the, all the, the things we may don't need to retrieve them from the consumers, just the, the below parts, this, this annotations object, the start line, the end line. So, annotation novel messages. So that's it. Okay. I posted a link and get a, just showing you how they get her branch source plugin is looking up the installation ideas. I don't think it's a group. I don't think it's a great idea for us to just store the installation ideas in a map and relying on a web hook event. Yes. Yes, that's, that's not very clear because maybe you, if you use that map, you have to, you know, persist that map informations because the next time when you restart the Jenkins instance, you won't expect to have to send you the repository installation event again. Yeah. So this just looks it up. Yes. Basically. Okay. So this is used to generate an installation token. Line 106 is where it looks up the tokens. It looks up the installation. Looks up. So it curious. Yeah. So I don't so using this. I have this method doesn't mean that we don't need to, you know, store those installation ideas and I can just directly use this, use this method to create a token and to allow me to authenticate as an installation. Basically. Yeah. Not all the way. Basically. So this is a credential. So you call the get password method on the credential and internally the get password call will return this. And it will also handle caching for you as well. So if you scroll down to line 137. So what 137 is just down the bottom of your screen at the moment. Yeah. So basically calling the get password will handle it for you when you retrieve the credential. Still I'm not. So this, this, this method is just works as like the, like this line of code here. So basically it works like this. Okay. Yeah. Exactly. Okay. So we still have had to, you know, have some way to know the installation ID. No, you just need the app ID and the, and the organization. Oh, you made, so you made a query to look up the installation ID. Yeah. Okay. That's cool. So I think this answers these questions about, I think you have asked a question like this right here. This is one of my questions was exactly this thing. Because if you do it in a map dynamically and think it's just down, you don't see any. Yes. So it's better to query for it. Yeah. Yes. You saw the problem. Yeah. The map is a problem I want to discuss today. So yeah. So I think if you just change it to use the GitHub branch source API for this, then you shouldn't have this problem at all. It should just be handled for you. And we can always adjust the plugin to make to, if we do need to expose more of this API we can. If you need an API for getting the token. But for now, this is just handling getting you that the, this, the bearer token that you need to pass the API. That's cool. That's cool. So I think. So do you have still other questions about my prototype? Or we can keep going over our agenda. Yeah. One thing I was wondering. So currently, from the perspective of the warnings plugin, I'm just interested at the end of the build. So if the build finished, I think it's okay for my plugin to report the results somewhere. Yes. Actually, I don't really care about the progress during a build. Yes. So, so basically you are on the warnings next generation plugin has, you know, get its reports during the, during the publishing stage, I guess, right? So, so it's, it's definitely before, before the uncompleted, you know, before the uncompleted event triggered. So, so basically what the consumers like the warnings next plugin, next generation plugin has to do is, because I have earlier attached the, attached the actions to the run, right? And the run and the action bears a check run source. So, so what you need to do is to update the, the, the, the fails in the source. So here this is the source, the source I provided here, the extends, they implement an extension point. So here, this is, you know, we need, we need more discussing here because we have so many parameters that we want to retrieve from the consumers. Maybe we should not, you know, implement this in the class. Maybe we should use some, you know, like X mail or, or some other things, but currently I use this as a class. No. So if you, if you implement, get external ID and get started at and get started. And this method of the world invoked when the, when the job is incomplete and I can retrieve the, so I can retrieve the, the, the information, the parameters from the consumers. So does it answer the question? Yeah. I think we need to talk about this a little bit in more detail about this is not nothing we need to do today. Okay. So the big question is that we have so many, we have so many parameters. So I'm not sure whether represents name as objects as classes is, is the right way to do. So class is fine. I wouldn't, I wouldn't add everything yet. It's just at the important ones. And then, and then people can come asking for what they want or. So the next thing is pipelines work. I'm not very familiar with the pipeline. So I find some resources from the Jenkins developer guide. And I think so from what I've known now, the pipeline, we just need to, you know, like, I implemented some builders and the pipeline will like magically, you know, compatible for plugins. Is that I think in this pipeline. I think I have a, I have a post about making the plugin pipeline campaign. I think you have a link in the get a channel. Make sure pipeline. It could be in the how to how to guides down the bottom. How index of all hell to guides last line here. Here is what this is all about the pipelines I know from this post. So, so what I'm thinking is that maybe we should, you know, like, like, those parts, these parts, we may, maybe we can, you know, implement them as builders or publishers. Then this may be a mix and make this pipeline compatible. Are you thinking about adding a step which allows people to report custom checks? Yes. Yes. The goal is like you are lacking your. I think your post about the current users only can, you know, like, update the information in status form like they can, they can create, create the runs about the code, like they can use the reports from the warnings next generation plugins or coverage plugins and they can report them to the GitHub. That's because maybe they can, maybe they can, you know, they can't access this information in the pipeline script. That's that's one of my questions. So, does this necessary to you to make our, you know, make our plugin pipeline compatible and or maybe make same configurable by the users? That's also my problem. Actually, I think so that we need to make this happen in the beginnings. So I think the first thing is to have an API for plugins. And if there is still some time, we can think about it to create a generic step that can report some texts or some notifications. But I think the main focus should be on support for plugins. Okay. And I think this could be added later on to have some generic thing. Yeah, I think this is in the night and the nice to have stuff like it'd be great to do. So we'll put off this things. So another thing is also the general API. Yeah, I got some code stuff from 3ds proposal. And he defined some general API, some code steps. I'm also thinking about the general API. So here is the idea from the. So actually, I think this, this, this method actually, you know, like describe what our plugins have done, like publish a report to GitHub, like subscriber trigger events, like possible report from the customers. But I'm not sure whether we can this, you know, this general API really works. Yeah, I'm not too first in the Jenkins extension points and creating the APIs for other plugins to use. So when I first think about the general API is that when I saw because now we know for GitHub we use a GitHub branch source API. So maybe we, maybe we, maybe we can use the GitHub branch source API for the GitHub and Bitbuck, Bitbuckate source branch source for Bitbuckate. So this is the first thought when I saw the general API. And I don't know whether that's feasible. We could possibly, we could possibly publish our API separately to the implementation as well. Because the GitHub checks plugin is probably, it's going to have to depend on GitHub branch source and a long list of other plugins probably. We possibly might want to have our API plugins separate. Okay. So now I understand the question. Yeah. Actually, I'm not sure. I have also implemented a plugin with, which is requiring Git and I created an API plugin to make it yeah, extensible. For instance, use subversion. But I think this is something we can look at it afterwards. So first, just create an implementation that works. And then we can see if we can extend it in an API. Yeah. Just publish it to the experimental update center. Well, first because I mean it works and then we can publish it to experimental. So then we can enter it. Okay. And one thing that I'm not really sure about it is the number of Git API plugins we have. So we have a Git branch source API. Yes. And what is the GitHub API? So I'm not sure. I think you have listed them here, right? Yeah. Yeah. That's very confusing. The first one that GitHub API plugin is confused me at first. So that's a typical API plugin in Jenkins for an external library. It just wraps GitHub API and provides it so there's only one copy running and we don't get class-class conflicts from different plugins running different versions. And this is called the URL for GitHub for us. Yeah. So it handles all the GitHub API calls, all the authentication and most of the caching, although GitHub branch source is doing some of it as well. Here. So this is the page, the home page for the GitHub API. Oh, okay. Just low level API. Okay. Yes. And the GitHub branch source is everything we need. It's the main. Yeah. The main plugin we need to depend on. Yes. We have to retrieve the source. The SM have by using the SM API. Even if I, so I'm not really familiar with the GitHub branch source API. I'm just using the Git in Jenkins. So if I just want to use a git and GitHub, is this the GitHub plugin or is this something differently again? There is another one called GitHub plugin. What is this plugin doing? GitHub API. There is a GitHub plugin. Yeah. The GitHub plugin wants to get confusing. It's, yeah. Yeah. Okay. Maybe I should look afterwards. How this plugin. I can have French. Okay. Yeah. Branch source API is kind of, you know, Oh, okay. Document here. Here is that. Yeah. That's the user guide. That one. Yes. This is like the here. You can see that you created a GitHub organization project. And, you know, so. It's, you know, it's our, our CI server looks like for now. Yeah. But can I use your plugin without the GitHub branch source plugin? Or is it intended? So, I don't use the GitHub branch source API plugin. So that, that's what I was just mentioning about possibly going to separate out an API plugin that doesn't depend on anything get up related. And then the, then our plugin just handles that extension points. Just so that all the other plugins don't have to depend on GitHub that want to contribute here. Yeah. The biggest problem for if, if our plugin depend on the key plugin, instead of the branch source plugin, the biggest problem is that we, we may not able to, you know, like retrieve the name, the name of the GitHub repository from the SM API implemented by the Git plugin. So, so, so that's something. So we can do this step. These two steps we can, we can do it. We can retrieve the source. We can retrieve the head. Okay. Okay. So the GitHub plugin, the GitHub plugin is that we depend on because we have to subscribe the GitHub event. So we just use a little part of it. The green, the green class is provided by the GitHub plugin. And we just extended this and we can subscribe to the GitHub event. Maybe that would be a good idea in your design document to have the actually plugins also here that we are required to use. So yes, from which plugin. It would be a little helpful for me because I'm not familiar with the GitHub plugin. Yep. Also for other developers. Yeah. Okay. So, any other things to discuss for? So that's possibly about my, the things I want to discuss for today. So. And one thing I'm not sure about was the, the action that you are creating. Is it just so you can find again your intermediate results? What? Sorry. You are ready to spring an action in the end of your design document. I think. Can you go to. Yeah. And this action is just to store. Intermediate results or how. Or what are you? Why are you required to use it? Yes. It's just, I need to attach the actions to the wrong. So, and carry the check on results to the, to the wrong side. I create this action and this action is actually a wrong action. So this is like the, it's like the warnings next generation. I think you have the result action and result. Yes. But I'm showing something in Jenkins, but the actions are just here to show something in Jenkins. And you don't show. I think, I think about this a little bit because. If we don't need the, the. If we don't need to store the installation ID here. And maybe we can get rid of this result action. So. That's, that's why I'm currently using it. The installation ID and to attach it to the wrong. Okay. I understand. Okay. So. I see other questions. Okay. About the status API and the, the, the checks API. Yeah. It's also very confusing. I'm not sure. Okay. No, no, no, no. So you can see here. And we have two, you know, like two checks. The first, the, the, this one, the continuous integration. This one is, is, is in the status API. It just leaves one message. This comment was good. So if you go into the details. If you go into the notion of the Jenkins instance. So you can hear this notion of the instance. But if you see the detail of the checks. And you have got to the checks. Yeah. That's a difference. Yes. But my question was, is it configurable? So, or is, do we now get both actions or both results? Yeah, we get both the results. We should be able to suppress the other one. Okay. So there's a, there's a way to, there's a plugin that turns it off. So we should be able to do the same thing that plugin does. And disable it once we're stable enough. The status API is a status is created by the branch source. Yeah. I guess. Yeah. So, so, so any other questions? So this, I just, I just posted the plugin that does it into the get a channel. So there's a, so very easy to implement once we want to. Yeah. Okay. Just say no. Okay. Well, assuming we can add a trait automatically. It's easy enough for the user to add it, but it should, should be doable. Otherwise we can update the plugin if we need to. Okay. So, so I guess that's all for our today's meeting. Thank you. Thank you. It was helpful to understand everything. Okay. I think the, the, the, the, in the next meeting we'll have to talk more about the, the, the API design. The milestones and some things like that. Yeah. It's a good idea. Okay.