 Okay. Okay. I'll share my screen. Let me see all everything that I have to share. So many tabs. Okay, perfect. And this is, this is the, you know, just started building off of Hello World Builder just changed the, you know, whatever these, like whatever is going to be displayed to the user. So, and I have a very simple issue to keep me sure it's running. What I'm going to do, I think it's running well. Do you want to see my Chrome? Yep. Yeah, we can. So to just get a background again, you have API which is, which is sending out cloud events. So this is just pulling the, this is pulling Jenkins native APIs like Rust APIs. So there's, you know, I can also pull up the end point. This is, this is the starting point and then it goes further into the other. Yeah, if the job is building, it will go to the job and test. So, you know, it's going to start from, and it's, if the job is building, then go into the native jobs API and see the particular information. What build is building, if it's completed, if it's in queue, or the description for jobs like that. And finally, there's also the other particular, like that is not what I'm using right now, but I'm really thinking about using it to get information about the build itself, which would be the API. I do not have, I'm looking into tech tons. Even the tech ton is emitting or it's like similar events and it has events for, if I'm talking about a task or a job itself so there's one job is started when a job is filled, and the job is building or running. So you know this is just demonstrating again. And you know this is not perfect. This is just the test the polling is really really bad right now the timing and everything it needs to This is a good start. Okay, yes. Um, so, you know this is the data this is like the cloud events data has the source. This is, I was to click on it. I am to click on it. Okay, it works. Amazing. So this is just you know the job is building a new one. This is the data itself. You know the lock can go into the data that we want, but since this is a simple job I was not really sure what all can I put in you know we have the URL we have the I can put in actions. I'm not entirely sure actually this is something that I wanted to ask you guys was what actions usually by telling about a job. I'm not sure if build actions are important at this point, I think when it comes to build actions we might have to ask someone who is so a little more experienced in that. We should probably approach someone in Jenkins who's who knows more about build actions, but what we can do at this point is this is like a very good start. Um, we can figure out. We can figure out what others see he type feels that we would like to fill for the cloud events itself. So right now, you're filling up what are fields over there. So, right now there is the job name that is on the number like the bill number itself. And then obviously you have the URL that's going to the source of where it is generating from. And I am trying to build the event for whenever a job has ended, which is a bit tricky, but we're there. It would be sort of a result is success or result is failure. I've been working on that a bit, not a lot but I'm researching on how we can start with the event of what happens on a job bills. So that this is a bit of pulling the API issue because I thought it would be easy if you're doing Jenkins rest API client for Java. But I don't know it's it's natively inside of Jenkins plug in the media. If I run it outside of it, it works fine. I want to move it inside of Jenkins. I'm getting several events and issues. So I just thought, okay, now I'm just going to write an API caller, and then we can work around that. Have you seen the code for the web hook trigger plugin for the what for the web hook trigger plugin. Yeah, I, I looked at it a little bit, but not not a lot like not an idea was not able to, you know, there were a lot of things was not able to really get around it because what happened, like starting with things and there's a lot of things. But it's something that I'm like looking in as a part of the research or just. So, um, as far as I know, I think the other trigger plugin gives an endpoint to receive an HTTP request on. So if if you want, we could sit down and kind of, you know, just go through the code and figure out how it's doing it. It's like meet the code wherever you might have problems. While you're reading the code, you can just ping any one of us and ask, like, what is this part of the code, what, what it might be doing. And there are. And I'm sure the author of the plugin might be around, but I don't think we might need to go there just right now, but we can start just kind of like reading the code and figure out how it's doing that first. Kind of just like, you know, doing a dummy implementation on our side. So I think that's going to relate more to Jenkins consuming cloud events. Yes. Yeah, you're trying to pull it from the from Jenkins. Yeah, um, yeah, I think it's like when I say pulling, I think it's more for me to just understand all the different endpoints within Jenkins and how can we get the information that we need. For example, when a build has started. Um, there's not, not like an exact information that says, okay, this has started now and this is running now. So just the differentiating between build and then building a builder like running off a build. And then finally, when a build has ended like that exact and that exact point like that exact. And I know that we can go into another API that's going to be information about the build and this says, okay, the build has finished. But I understand now what you're saying so I got so I was completely off point then. I guess you want to understand from Jenkins itself like when a build starts and ends like those exact moments like those events in Jenkins inside which you can read properly. So that's what you want to know. Okay. So in the class, you know, like there's so much and yet, yes, there's information about like the, as I said earlier, going from API just on where there's the color and it just means it's not building yet. It's a job that's present. But if it's like blue under score and may it's like something that's building and then going inside of it, just understanding the cloud even that we have to figure the job that hasn't started. The cloud even to trigger just to say, okay, the job is running right now. And, and then from there, going into the build it's, I have thought I, I think it's thinking that it should work, but it doesn't. You know, I have the code for, okay, the build has now succeeded or has now failed. I'm not entirely sure why but I am trying to understand how that the entirely pulling system is working inside. Send something through you. Just let me know if this helps understanding it on the chat. Is this something you've tried. Okay, this is bookmark. This was something I added to the design document at some point. I think this is something that could help probably because they've, they've already implemented this so kind of, you know, listening mechanism where, you know, on finished or like started they do certain things. But probably get some inspiration from here and just extended tool, kind of support cloud events. Do you think that would you happen to know why the Jenkins Rust API Java client working. Like, I'm pretty sure there might be an issue with my system itself because it might be trying to find different dependencies. I did look into the tree and I did not find dependencies for like. But I, you know, if we were using it, it would have been so much easy to just go and get whatever we need. So, are you trying to do this, like, are you. Sorry, this is too noisy. Um, so are you trying to pull the endpoint from the plug in itself. Like you're trying to pull the Jenkins endpoint from the plug in. Yeah, that's what I'm trying to do. So, um, that would be good as a initial starting point. But it would be nice to have something that hooks into the eventing mechanism within Jenkins itself, where we get to know, you know, if something started off. Um, so you could, uh, one sec, one sec. Sorry, my bad. Okay, so yeah, I was saying, um, to start, I think it's like a pretty easy thing to like kind of just, you know, pull the rest API endpoint and see what is the state of the job at a certain point. But ideally, it should like hook into the eventing within Jenkins itself and then, you know, send out events that way. Otherwise, if you think about it, then we are doing like a two-way thing. We are first going to pull and like upon some change, if you see a change, we are going to keep going to keep doing that if there is a change, then we send something else out. So there's like a two-way thing happening on two different directions. So instead, you wanted to go in like a smooth, single, like flowing fashion. So like if something happens, then the plugin gets to know and then like internally and the plugin will send out. Yeah, I think that makes more sense. And I think that can also solve some issues with the polling itself. And like the life cycle of the polling is pretty dependent on the user of the plugin. You always have the thread be running in the background otherwise for polling and it could, you can, you can see that as a overhead in one way. And easy way to kind of get rid of that would be to kind of just hook into this internal Jenkins eventing, which the statistics gather a plugin has figured out. And I am just like speaking based on what I've just seen in these plugins. I haven't implemented it as such but this is something for you to look at and think about and see what works best for you. Right. So, like in the architecture pattern that you are saying we should look into is like an external system inside of outside of the plugin but as part of Jenkins. And so how is that going to look like for a user who wants to implement this plugin? And just because what I have right now is like the user is going to enter the URL for this thing. I'm sorry I wasn't able to show that part but it's like already configured on my system. So the user enters the URL for this thing and as soon as like, you know, as job is started the polling starts as well. And then similar to that, as soon as like the polling starts and the event is being emitted to remember the URL is and stuff. So I'm just thinking of how could it look like. So the URL for the sync would be outside. The sync is obviously outside Jenkins. And the sync is where all the events would end up from Jenkins. So you would be doing kind of like a post request on the sync initially. Yeah, yeah I mean yeah that's what like I had in the issue that I'm running right now. It's just receiving post requests from Jenkins like the Jenkins plugin but like what I'm trying to understand is if we move the system out like the polling system itself outside of the plugin. But I think I might have to read on that to understand the architecture better. I'm getting a little confused. I'm just trying to understand so when you when you talk about polling. In this case, the polling is being done by the plugin. It's like it's being done inside the plugin so it's so as soon as I'm like running the plugin, you know as soon as that that as soon as a person adds a plugin into their like a user enters a plugin into their system. Like obviously then it becomes a part of their infrastructure and and and and like pulling starts right at that moment so as soon as a person like clicks on build now. It continues to be pulling the API is which are like I have I have in the code. And then you know whatever it figures out depending on how I would it is pulling it is going to send a an event to the sync that I have figured which is outside of Jenkins. Like an HTTP sync. So currently, how have you written the polling right now so the polling is working against the job. When it starts that's all. Well, it's running. It's like, okay so I have to. So basically it's as like as I said earlier to starting from the API like the first thing I was just like API Jason, which is information about the Jenkins system like the number of course the number of jobs which are in the system at that moment. Um, and if it figures out that the if a certain job is building based on the color of the job that it's going to right there and then it starts. The other one which is like looking in the job itself so the test jobs when I started it and it figured out okay the test job is running that it went in and then it looked it looked into okay what number of the job or like what is the number of the job, the build number that's the name, the description and everything. So then it returns the event when it figures out okay the job is willing and here's the number here's name here's the description. And I also have like a build for when it ends I mean it's not different it's just like going to step further into build itself and seeing if it's still building or like the build itself is it still building or if it has stopped building and then generate another event which would be okay the build is failing. Does that make sense? Yeah, it makes sense one second. I'm so sorry about one second. My bad. The meat is here so it's like really noisy right now in the house. Okay, so, um, yeah it makes sense. So, I think this mini demo was like a good place to start. But imagine now at scale like if you have a lot of jobs that you're pulling for using the plugin, the plugin will have so many threads running in the background for each different job that is there. Like it will at some point be like a large overhead created by the plugin for all of these. So, just like in like in my head when I think about it just is a good place to start. We have to think at some point of like somehow getting this so you know, you know, a singular like like straightforward fashion where the events kind of triggers the cloud event, the event within Jenkins will trigger like you have to that's why you have to understand like how these smaller things in Jenkins work somehow. The build step listener like I'm looking at the build step listener over here, the build step is extend. So in the start plug in the build step starts listener which extends a build step listener is a Jenkins class itself. So it's so it's comes under Hudson model build step listener. We could use that. And similarly, there is a run stats listener. And there is a, there is, there is a class called run listener which is being used for this one. And this one. I think run over here means a build run itself. So in this case they are getting the run which is happening at that time. And it says, Okay, if the run is started, if it's in progress, if some if environment variables are there so a lot of information is being picked up from these listeners themselves. So, so I think as a next step it would be a good place to see if like you can kind of reimplement this into have cloud events be sent by these listeners. So upon start of a job you started you send a cloud event saying that okay there's a cloud event. So this build is started and there's a cloud event for it. And right now you're using an HTTP so so for listening to these cloud events or like for the sync rate. Like, you can, you can just use the same thing and try it out. Does that make sense. Do you think it's like probably the better next step, or do you have something else you would like to try. I think, um, yeah I think that makes a lot of sense and this the statistics gathering plugin and it looks like a great place to get an idea of their implementing it. Yeah, I think like this is like a really good place, and definitely, and, um, you know, the men, like start implementing this and like testing out with the, the evidence part of the cloud events. And if we have that down. I think the piece we have an idea of how just working with cloud events and Jenkins can look like so I think the other stuff would be easy, easy. Frankly, I'm very impressed that we've already reached like sync state to like testing this out because this was supposed to be only like community bonding chatting and like how many party time that we have you know figuring out what this is about and getting to know each other and stuff. But yeah, this is great. You already reached a state and awesome. Yeah, let's also do that in a month. So I'm just sitting here drinking orange juice thinking I wouldn't have to think of this. But yeah, this is great. This is great for awesome shooting. Thank you. Yeah, I think we will just move the community bonding towards the end so just finish early and take all the time. I think that'll be that'll be more fun because then you know we don't have work to do it is just like bonding and party. Yeah, that would be great. How feeling that you'll be in deep till the end that you will be talking to probably like other communities and figuring stuff out we wouldn't even have fertile. Yeah. Let's see how that goes. Yeah, but this is great. Let me know how that goes done for you with the business stuff. I just got out like I found this project while I was writing the design dog, and it just seemed like the perfect thing like this is exactly what you're trying to do. All we need to do is send cloud events. So, yeah, it's just, it's just pretty straightforward when you look at statistics. Yeah, it's a great, it's a great starting point and you're you're doing awesome sure see I'm so impressed as well. And the owner. This is not this is not your work this is vis a vis Jenkins and some of the code you will see internally from the from the users perspective at this point, there are certain words that shouldn't be showing certain older terminology which we're moving from the project, like master slave. So, in your own work that you're writing, instead of using a word like slave if you use agent that would be great and I will get you the complete list of word replacements that we're using so that it's done correctly but if you just start off that way then it's nice because then you don't have to go back and change your words. Yeah. I'll just maybe ask you guys once again about the events itself. I know. Let me talk once look into how or like one says tecton emitting. And as I said, about jobs itself there can be when a job as a started when a job is building when a job succeeded like the job is ended it succeeded and the job failed. I'm starting part of the job has started and building needs to be two separate events or do you think like, you know, a job is started and when the other event is emitted, which would be a job is failed or job has succeeded it would kind of cover the space of a job is building. Well, it's good that you're thinking in this way, or at this point, but to start, it would be a good place to completely map out all the events sent out by Jenkins first, and then map them out to like a larger context. So in tecton what they've done they've done something similar. They've, they've, they have this event type or unknown, which, which is kind of like condition passing kind of like an event type. Let me send you the Cloud event table. I don't know why I'm typing with one hand. Okay, so they've got this cloud event type, especially for unknown, where if a condition is changing, they really don't know what's happening there so they called it unknown, not condition changing. So, in such times where there is not there's a certain event which is not explicitly being given out by Jenkins, we have to use terminology like unknown. So, it is good to document these things, and kind of for us to get a clear idea of what we are trying to do in terms of you know mapping out how the Jenkins job life cycle is showing itself in terms of events, and we mark something you know Jenkins job is starting or like computing is like unknown, but while naming these we have to be sure that you know we are not reflecting what Jenkins is already saying, because if we reflect them like inaccurately, we kind of give the impression that you know, this is what Jenkins is saying, but this is not actually what Jenkins is saying because Jenkins is probably not saying anything with that. So, it's to start off, it will be good to like just map all these events that are being created by Jenkins directly onto cloud events, and then later on figure out with them, okay what is missing over here. And then we can like add certain things here, you know unknown events that are in there, which probably are there, but are happening in the background and we just don't know. So, and those also might need you know, a different mechanism of sending, probably if it is not directly told by Jenkins itself, how do we figure out if it's in that state. Yeah. And when you say map out, like Jenkins events. Um, is there like a specific guide to okay here are all Jenkins events or just like map out as in, um, just like mentally just understand what is happening and then sort of write it down. What is there like this is. The thing about that would be just take each Jenkins resource that exists resource type and see a listener on those type exists. And for each type would exist and for each listener see what event is emitted. So, you, at that point you know, like, okay, these are all the mappings that I need to do. Like the life cycle resources, because there are not resources just for like jobs and bills and stuff that is for projects, and I think for views and these very Jenkinsy things that are there. So, actually, let me see if I can pull that out. Yeah, so start editing the page for a lot of events on Jenkins project site, just so that all of us, plus people outside of, you know, our team can just be staying. Sorry, I didn't catch you. Wait, what? I didn't get you. Yeah, I just, yeah, I just said that the, I'll start editing the GSOC like our project page and Jenkins GSOC. So, you all know that where we are in terms of progress and also people outside of the team. Oh, that's so helpful. I think I looked at a similar thing earlier but it was all terminology related to a job. Yeah, this might be helpful. I don't know to what extent, but like, I don't know if any like some of these like cloud executor workspace even have listeners of their own, but it would be a good place to, I think, I really feel like the Hudson model listeners package which is there. You could just like check what all this, what are the listeners classes are there under that, and that's probably the best place you could figure out, you know, how to, from where you can like map these cloud events. That's probably the best place because this is just documentation and documentation sometimes isn't like the source of the code itself. So, probably look at those listeners classes. Yeah. All these listeners classes. Okay, so I have found, I think there are like six listeners over here, which you could use the other five listeners. So there's item listener, run listener, same listener, same poll listener but based on what we saw, there are some other listeners as well, which we, I don't think we are seeing the movie right now. Do you think this is a good place for your next conquest, Shruti? Yeah, definitely. Yeah, I think the statistics, the other plug in, and most likely class, the other listeners, I think just that's a really good place actually to get an idea of what we can do. I'm glad to hear that. I'll have to drop off in a bit. So, is there, are there any other voting questions? All right, thanks for for joining us today. Awesome work Shruti. You've been amazing in your first week of community bonding already tackling and exploring the code base and starting your work. So really impressive. I have no more questions for today or anything, anything else we need to add or bring up for this meeting. Okay, great. Thank you all have a very good week. Bye guys.