 So I'll start with what I have done for this week and I'll share my screen to see what I'm supposed to share. So I have, like, I have Jenkins running right now and these were jobs which, like, I created just like test jobs. So right now what's, you know, for the things what it's doing, this is basically like Jenkins as a source. So we figured that we'd start working with Jenkins as a source first and then once we have a bit of, like, more clear idea of getting events and stuff we can move into configuring Jenkins as a thing. So this is global configuration and inside of it, I'm just going to do a little thing. So this is going to basically add an endpoint or a sync which is configured to receive cloud events and I also have a server running which is just a simple HTTP server and this particular one does not, like, it's not parsing cloud events data but we are sending over cloud events data and it's like able to look into headers. I also have a server which is able to, like, look through cloud events data and then sort of send back a response in that format but it's not running right now. And the events, the last we talked about starting off with events which are more sort of used so in terms of like a job, we'd say like a job has started, a job has completed and if the next step of the job, like the last, what's it called, the artifact is built, we can choose what events we want and maybe all of these events and just maybe going to do job start it and also add another endpoint. So I'm going to apply it back here and are you guys able to see my VS code or do you want to just see my browser? This is the browser at this point. What about now? Stay the browser. Okay. I will server. Yeah. So I also tried making sure that it works in a distributed system so my other region, it's offline. I started once like we display this simple with just one simple like executor. So let me just like start a job. So this is what's being sent inside the cloud events data and this is like how a cloud event is configured right now is it's using a binary format instead of a structured format and what that basically means is that it's setting headers separately and then it's setting the body separately. So this is, you know, this is like setting up, setting up like we want to send a JSON object which is like in a byte, like a byte array which is being configured right here. So this is like the cloud event which we want to send and going back to job listener or stage. So we're so this is basically like an enum and it has the three stages, which is like a job is started, a job is completed or a job is finalized. And depending on whatever the current configuration of the job is, it's just going to sort of put in information into the JSON document and then convert it and then put it inside of the cloud event data. And as I said, we are right now using a binary format, although I think we might want to move to using like just using structured instead, instead of binary, because it's I was like reading and it just said that it's more, you know, if you want to multi route, it's it's it's better to keep all the headers and the data together as the payload. So this is sort of the payload that we're going to get and since this is configured for started, that's why it's getting all the started, I can also go and add another event and I want to get an event, every job field job start is all of events basically. So that's, that's Jenkins out, I'll move into the code and how it's figured, and it uses it uses listener implementation and right now, you know, there's the abstraction that we were talking about. I don't think I was completely able to understand where exactly we might need that sort of implementation, because, you know, since all of these are, like, if this is, for example, a run listener, which is basically just notifying for run and then there's item listener or job listener, you know, so what, so this is essentially like, we are going to need all of these listeners added as extensions and then have their whatever methods that they have, we want them overridden or maybe not whatever are. Circumstance looks like, but when we talk about abstraction, the thing that I'm sort of thinking is, I don't feel that there's anything which is really common between these implementations. So we can like, pull maybe some constant fields out, for example, job name or, and then put that into, like, like, like an interface instead of like an abstract class. And then just first figure out what's common, what sort of extra methods can we add? I was looking into the GitHub Auto status job and there was the, like, do you want to send test reports or do you, or do you want to send error reports for other jobs? And I think that's a really good method that we can have implemented by other listeners. So, yeah, so right now I was just using a job listener here and it's just extending the listener, which is the enumerations, which we were looking at earlier, and then there's a build model and job model, which just gets information, you know, URL, the other current ID and stuff. And the cloud event is, you know, you know, you can, you know, you can, you know, and the cloud event message writer is what's needed for cloud event and it's using one of the cloud event and dependency to write any, you know, like each right into HTTP and send it over as an HTTP class. And then this is the endpoint, which is some sort of some configuration that's needed for the jelly file and also some configuration that's needed to send. And I need to refracted this out, like the send to some better class or something. I don't think that this is the right place to put it. And the stage is the enumerations. One cloud for now. It's great, Trissie. That's really interesting. Jeff or Rohit, would you like to give you back? I mean, the only thing that I saw we went through it briefly was just stuff like a hard-coded URL to HTTP host, which I assume is just kind of placeholder code. In the, for the sync? Yeah. Oh, that was. Oh, I'm sorry. No, no, go ahead. No, no, no, the URL for the sync. No, that's, I think that's a different place. That's just for like a cloud event to send the mess. So this is not the URL that it's getting out from the jelly file. The sync URL is coming from the jelly, which is then it's using to send the event to Let me find where that I think it was the last piece of code you were showing maybe Trissie, is this up on your GitHub, actually? For us, but also for the other mentors, they might want to have a readover. Yeah, yeah, yeah. Yeah, so I, it has a lot of like, Debuggers in right now, but I'm like cleaning the code and I'll put it into GitHub today, right, you know, right after the meeting is done, and I clean up whatever is required, I'll put it on. Okay, awesome. Thank you. Is there, there's something that you can submit a pull request against or is this the initial implementation? Yeah. Okay. Because if you had a pull request, then it's easier to comment on specific things, I think. Yeah. Yeah, so with how he actually created a cloud events plugin. A few months back, so I'll just send a full request to it. Perfect. I actually think I, let me just go back and see what we're looking at here. Like looking into this like end point file, I like, like right now I real, I'm realizing that I hard coded it there in the end point class, which basically is configured for, you know, it has to sync your own it has the event, whichever that event is configured to be received So if I go into the jelly file. So, so all of these events, and whatever, you know, a user is going to choose. It's going to be represented here and then if I were to go back into the numerations, you know, this is the configuration needs to go here for sync URL and this is the URL that I'm sending it to and I'm not using it here. No, there's the one line line 84 was the one that I kind of I was wondering about. Yeah. But again, it's a, if I can look at the pull request, I can just make that comment and it's probably a more efficient way. Yeah, yeah, that makes a lot of sense and I'm totally going to do that is just I don't. So I did another question since there's other people I noticed for logging you use system system dot out. I'm not sure what whether that will create like the same type of Java logs that you can you can look at in Jenkins but I'm not super familiar with Java so it might be fine. I think you should ship to other logging libraries. Yeah, yeah, I think you guys are you guys are correct about that. And yeah, I think I just use that use that there because I was like, I just need to print and see but yes that this is the thing that I need to log and make sure that it it's into debug mode. So whenever person is doing that would be the correct way. Yeah, but I mean this this looks this looks great it's a good start and and I mean the code is like easy to follow and understandable. Just like this brief intro so I'm, I'm pretty, pretty happy with your progress. Yeah, amazing work. Thank you guys. Learning to write Jenkins plugins is not trivial. Especially jelly. Jelly falls, or quite a hard to figure out how they work. Finally got it working it was so fun. Did have few questions actually. So the, the thing about abstraction or just maybe just having interfaces that we were talking about earlier, and looking into. So I was looking into how you'd implemented in GitHub auto status plugin. And, you know, since it has those where where those like listener implementations need to go to. I think that that was a very great place to use this abstraction for for common you know methods or just maybe variables, but do you think, or I'm just, I think that over here. I don't know if abstraction is necessarily going to help, but I do feel if we are able to think of any situations or methods where we are absolutely going, which are going to be common between listener implementations because, like for example a run list like a run listener has an on started on finished whatever queue listeners completely different. And all of them share different information so I don't like there's not a lot of common information besides, you know the name of the job, the description and stuff. So, I like I want to hear your guys idea on how or where can we leverage just maybe using interfaces and like putting common methods, or just like, if there are variables which other listeners. that can improve functionality and other different classes can use. So I mean I think I kind of trust your instincts it sounds like you've spent a lot of time thinking thinking it through. I think my guidance was just around. Let's look for you know people write write a new Jenkins plug and they tend to go find something that similar and copy it. And then so they create a copy and then that you know it gets out of date with with the thing that they copied from things have to be made into two places. And I just feel like this is the sort of thing that that that's common like I could see other plugins maybe wanting to be able to send events. So, so I don't have anything specific but but I just wanted to kind of put it on your radar to be to be thinking about those things because plugins can extend other plugins so it's possible that some plugin may want to want to call something in your plug in it might be that that it's not and that I just wanted you to be to be thinking about it I don't have anything specific but when when I start looking at the code if anything pops up we can. I'll bring it up and we can talk about it but yeah if you don't see anything common don't don't create abstractions. Just just because because of that that comment and I think like like properties are less interesting on on an interface I mean it's to me it's kind of more about behaviors and so if the only thing you see is like common properties that to me that maybe seems a little bit less interesting. So but but I mean when you're talking about it I just got the sense that you've spent a lot you spent a lot of time thinking about it and your conclusion made sense to me. Yeah I think I was just like still you know I have sort of figures on my notepad just trying to understand where you know is that commonality that we can create and leverage abstraction because it is a really great idea to you know like have that implemented through an abstraction and have different listener implementations like leverage that and but I don't know if I necessarily am able to understand it yet, but I'm still working on it and all on extending other plugins though it was something that I was trying a bit earlier again as I said you know if I this if I am to extend the plugin that would mean that I'm delegating the task of having that like that event payload and being sent over to my or like to this cloud event plugin. So, so it's it's sort of tricky, because you know, for if you consider GitHub auto status plugin for example, it has those listener implementations and that's when it gets data right. So if there's a list of patient for run listener and run listener on started, which already sort of like a method that it's overriding. So, as that as the run has started, and I'm like, I'm again extending that plugin and as a running so started I want to get a lot of status plugin to send my plug in that event data and I will send it to the sink, but do you like do you kind of see the it well that contrast was a sort of different overridden on started methods because your plugin has an on start which needs to be implemented for to send me the event details. And it's just a bit it's just a bit tricky to get around, because also like you know whenever a job is started I would want to run the on start for my plug in and then I'd want to run the auto start or like the on started for the auto status plugin to send the information over. But I think it's if that makes sense I'm not I'm not really sure if I'm making sense right now. But, but okay I have what I'll do is sort of create a diagram of what I'm trying to say, and then I'll send it over to you as well. A bit more sense. But I just think that it will over complicate this process, because what if what we only need to do is you know get implementation as soon as the run is started, or run is finalized and send it over. And which I think is it's happening right now we just, you know for job started finished and also we looked at finalized or completed. I'm sorry go ahead. I was going to say let's let's just table that that discussion I don't think you need to create a diagram. I mean, what a good good skill to have in engineering I've learned over the years is knowing when to ignore advice from people. I hate to see you spending time on something. I mean my comment was more, you know spend some time thinking about this and then you've done that and I mean I can see that you know you're capable and you're smart and I trust you so I don't, I don't want you to be spending time worrying about convincing me. I'm good. It was a good. It was like a good place for me to think because I was just like, that can also be a way we can do it you know, like if I just had it handed over to me wouldn't have been as fun I think, even if it were just like jelly files as I was talking about earlier. It would have been fun if you know the jelly file was just like there. So it was kind of fun to figure it out. And I was also trying to extend like plugins in this particular plugin and seeing if or how does particularly the ones with listener implementation because that's the sort of the thing that we want to do. Also, you know the listener implementation on started there basically like non returning methods. So those methods don't return anything that's what we want to do is like as something is a started want to return something to another thing to you know get basically an event out of it. Yeah, I think we might have to go with a single listener implementation and then maybe like you know different listeners of course, which, which is also like sort of my another question about listeners itself right now. Well, what I had was a run listener and it will be simply. I think very easily extended to an item listener and Q listener, but we have and Karen and I were talking last time about having like computer listener, which is if a note is online or also does also work on scalable system so the note that I was talking about earlier like that the agent note which was offline. I tested and made sure that it works on, you know if there's like a distributed system and so so it was it was working. But in terms of sending events like this is this job was completed by so and so agent, or this job, or like this agent is offline so trigger this event. So you know that's also do we do we want to also have events about computers or just executors and agents, or just stay to the generic like jobs and cues and files and folders maybe changes. Yes. I mean, the short answer is that I think that events about agents will be useful. In fact, we were having problems with some of our agents at one point and I created a plugin just to write the name of the agent just so we could track because we suspected that some of them weren't working but so the long answer is, does it fit within within your project and so that's, that's what we have to decide. If you have time for it I think it would be interesting then does anybody else have any thoughts. So if I heard correctly this the question was about sending events regarding agents like agent creation agent. So, yeah, I think that's a good idea, like when a new agent is created or something but I don't know if that so are you thinking of creating that as an event that is created in the beginning, as in like one of the first events that are created by the plugin. Like for the plugin. Wait, I don't, I'm not able to follow through, like what do you mean the first? I mean, no. So, I don't, I don't think that would even be a problem really, but I was just thinking what are the first kind of events like you're going to tackle on creating. Oh, oh, that makes sense like first as in like the more important ones are the first first as in like something that happens on priority in Jenkins itself. No, no, like the first as in the first that you would start working on. So the first that I sort of worked on, like I was, we were looking at here I think you, you, you were not able to join at that moment was just like job I can put briefly share my screen again. So just so we know how like the UI and stuff looks like and how. Yeah, so yeah, I was in a little bit of a dilemma that's why I joined. But hey, Jeff, it's nice to see a happy real. Yeah, I'm sorry I missed the first couple I slept through one of them the other one I just space but I this will just become part of my routine every Monday morning and I won't I won't forget plus I saw the reminder today. I'm just like very happy that all of us can come together and work on this stuff. I'm sorry for like a little being a little late today, but hope I can also come on time and we can kind of sync on Monday. Are we're where are you located. Are you in India or are you elsewhere. Oh, no, I'm in India. Okay, so it's evening nighttime for you evening. Yep. Okay. So what is the global configuration for cloud events. And this was another thing that I was thinking. So you know how we were looking at, like, statistics, gather a plugin and how it had like things, and then it had like things for jobs things for QL things, but I mean things for Q things for bill steps. And that having it this way it makes it more modular because you know you just want to configure like a sync which receives only job started events so the thing does not will not have to do a lot of configuration. It's also one of that it's making it loosely coupled and not like super attached on single sync perceiving all of these events. When, if we are to add more events in terms of going on to other listeners like you and computer listener, I think the list will either just have to grow, or maybe we can say something like this is a bill. Like, over here we can say something like build and point and then particular ones. Anyway. Um, so this can, can you select. Do you just can you just select one one event at a time there or Um, so I can add more but here is just like one. Yeah, can you can you make this event into events and kind of like it could be where multiple events. Oh, okay. So you can, you can, you can basically configure multiple syncs is it. Yeah, yeah, I basically can send it to the end. So maybe instead of like, it's this endpoint doesn't work. So it's probably going to give me whatever it is this endpoint is not configured but this the first one is, and then I can learn some more to go somewhere else. And it doesn't matter. I don't know what spending time on this. I'm not completed. I'm done. I were to say, but at least and if I like, build it, I'm going to. So I did have a, I did have a thought about this, too. I want to know what other people think again, I mean, I don't want to muddy the waters too much but if there ends up being a lot of settings, you can actually create your own setting applet for the plugin. So rather than having it in Jenkins system. I wonder if at some point that would be useful. What would be that? What would that be again? Yeah, you can have your own settings app and I mean like with without I didn't know this but with the auto status plugin right so I just add it to the the config that has like lots and lots of settings and it's just polluted you can have like your separate settings applet. And I don't think it has to be jelly either. I think you I think, yeah, the auto status one had groovy files. That was very interesting. It's groovy is not. Yeah. Probably we could use configuration as code. I think that's a good idea. What is it? Does it use JavaScript for its UI or No, like you have to pass YAML. Oh, like you just kind of say cloud events, and then you say, what is the event sync and then probably the events you will be looking for maybe something like that. I see that that's that's a good point, but that's not necessarily UI related right that that's just we would want this plugin to support configuration as code. That's that's a very, very good point. Any modern new jug Jenkins plugins should Can you send them the chat while you were talking about also completely gave up the idea of using stapler because as I said last time it's like The binding that we like the binding with URL like object URL binding and I think that we're going to need that here. It's more. Yeah, we might need it for when we're configuring a sync. Since, you know, we need a URL to to be configured to see how events, but not not for source. I've sent them in a slack chat. Oh, thank you. So the prototype you've made is it just like a journey prototype or does it work with the sync. It works with the sync. Oh, that's nice. We're going to write some tests for it. Um, yeah, I was thinking about I have a separate a clone sort of where I was like testing with some genius, but I'm not a very adept one yet. But I think I will also get to that I was just thinking about that. I'll also get I just realized while asking that question that we are so early into this phase, like we haven't even started coding phase and already reached out. This is what this is like some good work though. I was impressed with the events just like one thing I was thinking like every time you've got to send a different event like do I have to configure the same sync on three different endpoints? Like if I want to say send the same like I want to send events to the same thing. At that point I would have to create three of the endpoints. Like you're saying that when I sort of send like job finalized job started job completed to the same endpoint. Yeah, yeah, yeah. Yeah, so there's like an all events option on there. So just in just then. So do you want me to share my screen again? I don't know. Oh, it's right here. I don't share this. So sorry for coming in late and asking so many questions. No, no, these are good. No, we need questions that makes the creative. I don't know on juices flowing in the right. Oh, anyway, I still have the most trouble just sharing my screen out of everything. This is such a big trouble. Anyway, so, yeah, but I think, yeah, even if it's all events, it'll send all of these events. So I think it still would be nice to separate like job events from Q events and Q events from a build step events. That would actually be nice like something like all job or all Q but I was thinking was you could have like a selector like you could add events like you are adding the configurations right if you could do something like instead of event, it will be like events and you can say something like under that like a button which says add events and you know you could add events from there like maybe this is this will be like two months jelly work. Like there would be a repeatable for events. So right now you are very repeatable for the entire configuration. Yeah, I think there is a repeatable for the event only like itself. The event or no event not event for the endpoints. So end point is basically like a Java class and I have a repeatable for the Java class and event like the end point has the sync URL and the event where it meets like where a particular whatever whatever event we want to be sent to the you. So that's what I have right now but you're suggesting that add a repeatable for the event. Because that it will be easier to select for like one sync if you want like a little kind of events to be sent. So I was thinking that sense. Yeah, I think that the reason I kept it like this or like the reason like I feel like this might be more modular in the sense that a particular sync is only receiving the particular event that it's configured for and I think that's if we if you're looking at EDA just patterns in general you know you you'd think that for example if you're like looking at Terraform or just maybe something like infrastructure has scored and you know as it receives a single event of a type node has failed. So that's one event so it knows whenever it receives that event it does not have to parse through a lot of information it knows that this is the event that it's configured to receive and then it will you know spin up another like agent or cluster or whatever it's configured to and similarly for if they're like the cloud bridges and in like Azure or AWS or something like that which are configured to receive one single type of an event and whenever that goes into that particular event or like whenever that sync receives that event it knows what event it's receiving and like with the state gather plugin I think it was like the UI with school but it was sending all of the events together and for everything that's happening inside a queue gets sent to a but again it was for a different purpose the purpose here is different than the purpose it was there but I think yeah we can we can also try how that might work in UI and also in inside code I think that makes sense I think for now we'll keep it this way and yeah it does make sense like to have an endpoint which might be configured to receive certain kind of events like in this case you've given like job created or like job related events so if that endpoint is configured for that then it makes sense to kind of make it you know that it only receives those events and we kind of don't load it with different events but I think we'll get to more in due time once the interoperability stuff kind of goes ahead in the event sync and you know we start seeing what kind of prototypes are being made I think slowly we will have to start aligning based on those ideas like how how we can make this work with Tecton or something like that but that's like that's like way in the future I feel like maybe three to three months ahead but yeah this looks great I think I think we are already this looks great like we've already crossed like covered so much around here That's nice We plan on working the coding phase Okay also with how I wanted to let you know a bit earlier that the coding phase actually started last week So we are coding Well I haven't been Yeah it just feels like everything is moving fast Yeah but this is great Yeah but thanks for letting me know So what is the next thing you're planning for this? So the next so the first thing is obviously extending this but that's not going to be super like troublesome or you know something that's going to take a lot of time but the next big thing I'm looking at is sync implementation and I'm looking at extension points for like webhook like plugins and obviously start with there's the generic trigger plugin and all the all or most I would say are extension points for actions since it gets tied to a URL so I just have to understand that better to sort of just make just see how the entire infrastructure and the entire system is going to work when Jenkins is configured as a sync especially because the events that we are receiving will not just be specific to a job but they can also be specific to say a node or like you know because I think I was looking at that and notice also and like a model object I think so if we have I'm still not sure I still like saying things up loud there's a model object that we connect our action to and that model object is our node and we connect an action to it so it's going to have a URL where events about that node can be sent or not about that node but like just events which might tie into that node for example some event has been received and we want to scale up our nodes and we want to delete or do something with our current system or agents and stuff so that's sort of the thing to just understand the implementation of sync and how can we use extension points if there are more extension points I'd love to just understand and read through them and see how we can do this and also tests reading tests I think you said a lot over there but I think but I feel like you've got you've got a good idea so at the end of the day this is going to be run by you so and I hope you've got the access to the repo yes I do and we were talking about it earlier and Jeff and Rohit mentioned that it would be nice if I like if the code is on on GitHub so you guys can look and comment so I'm just going to do some cleanup because you know my logger now it's not like a debugger log it's a system print and that's that's not good I'm just going to change it to a logger or something like that and also just clean up some more places and then put it there so you guys can comment and just see what's going on and I do have the access okay that sounds good yeah thank you for creating the repository it wasn't it was a hard task no but you know I was like okay if I not just exist because I think I would have I would have like I should have like I would have wanted to ask for permission to host our repository I'm not sure I think you would have got permission to host it it's just that before the project started I thought we you know better to probably we I even thought maybe we should have created issues earlier but I think I think we are in a decent place we could start creating issues if you want and then you know start working in that way but I feel like you've already you're already so driven that probably you will be creating them that yourself I guess I will sum up PR by probably in 24 hours I'm not going to say like right tonight because we're in different time zones in 24 hours it should be on there so everyone will be able to see also debugging by print statements is standard in many ways like everyone everyone does it all the time I put a link in the chat it's like a joke but you know I mean it's everyone does this Oh that's funny like I so I haven't been vigilant about these dates turns out so I just wanted to let know about the coding phases a little bit and do we have time to talk about this stuff Absolutely we have time I have time to stay on the call So the coding phase runs as you said from June 7 June 7 to July to August 16 so it's quite it's a good it's a good period of time or one weekend she's zooming ahead being awesome and this year has reduced hours actually so we're she's like is requiring less hours from the students to take into account everything that is going on in the world and how turbulent this time is which gives us a great deal of flexibility that being said would you have to meet certain benchmarks but we're way on track for that so a student could not say oh I will do all my coding in the last four weeks and it will be fine they do want to review process midway through just to ensure things are on track but that that is it within within that structure we have a great deal of flexibility and where we push and where we need some more time for for whatever reasons be it schoolwork or something is happening in personal life or just something is happening and it's really sure to who can set that flexibility schedule yes and again like you know thank you so much for being understanding and appreciate it really really important and also it's like so nice that I have such amazing team of mentors so amazing and I it's I think it's like unless you guys have like want to change the meeting hours or like change, I don't know the way we are meeting right now, I think it should be fine it works for me, currently the new meeting time is 1400 UTC it's a little bit of a faff doing these these conversions but I think that's the way it's said and it's set on the calendar that way but if anyone has an issue with that and I'll double check it with Marisha because I just want to make sure he can it's the one mentor we need feedback from and I want to make sure it works for him but yeah we can be flexible on that but that that is where it's currently set now cool was there was there something that was just that was just about timing but was there something else Rudy are you is this is this flow working for you with the Slack channel and the weekly meeting and now hopefully more more reviews on GitHub yes yes it's no I think it's perfect. And like I feel like if when we move forward, I might want to maybe do two meetings a week when we are more into you know the same phase I don't know how it's looking right now that be okay with your guys schedule. I'm fine with that. I will just say that Friday is another is the bookends of the week have the last meetings for myself. But but you know we can we can do another doodle and see what works for everyone. Thank you. Everything else is good. Good. Good you're doing amazing work. So I'm so happy. I don't have anything more to show or add right now. You'll talk more on GitHub and Slack. Yes, if you have any doubts like you're always around Slack so if you end up starting the same stuff, you can always ask on Slack. Thank you guys. That's so amazing. And if you have a question for me feel free to do add here or ping me directly because then it'll I'll get a notification. I'll see it more quickly. Great thank you all. And unless we have any more last minute advice or questions then good we can close the meeting pretty much on the hour. Thank you for showing your work for G that was really, really awesome work. Okay, see you all next week.