 Yeah, so I think this plugin or this doc is using that plugin and using Cloud event management, which is something I haven't looked into, but it makes sense that it will be something which is similar to just receiving and emitting events for IBM Cloud and anything that maybe triggers events in IBM Cloud or any event that happens in IBM Cloud, they want to send a notification over to a sync. So I think this is using the event Jenkins as an event source going into IBM Cloud events. Yep. And with the event sync at the CDF there are certainly people who are very involved in that who work at IBM. I can't have a notice the coincidence. Have you been able to attend any of the events? Not that you have to, but it just it just might become interesting. I wasn't able to yet, but I was talking with Vibhav the last time, and someone at CDCon from Fedora, one of the projects from Fedora mentioned that, you know, they're doing a lot around Cloud events, and then I was like, oh, yes, the event sync, and I should attend this. I then asked when it's happening because I confused the dates. But Vibhav said that it happens Tuesday and the next might be happening in July. Yes, I'm looking forward to attending the future because I think those are important also because they are cross projects and how they are using events and the Cloud events in their projects. Clara, you're on mute. Sorry, there was a London noise. And then I have too many tabs. I have it in my calendar, and I haven't been for a few weeks, but I have it on a Monday. So I don't know if you have, if you found the CDF calendar. I'll send you a link to the CDF calendar and we can double check times for it. Sorry, go on. No, were you saying something? No, no, I was saying that I just wanted to, because I think you said Tuesday, I just wanted you to know. And I think it is not today, but on my calendar anyways, next week's Monday. All right, thank you for letting me know, Carl. I will also, this week, I wasn't able to do a lot because I was kind of, it got really into watching CDCon, but then I thought maybe the weekend I'd be able to do something, but then I had to get my second dose of vaccine, which was so, like the side effects were so worse than the first dose. But it's fine now. And this week, I'm hoping to accomplish a lot. But I'll still do a little bit of the demo of how the UI has changed and what's new in how the headers are and leave in. That's great. And don't worry about this week, because I mean, I'm sure your work has actually moved forward well, but also, CDCon was amazing and I'm really glad that you were able to enjoy it. And then I'm also really happy you got your second vaccine. That's awesome. Thank you. The internet is pretty slow. You know, the last week, we were sort of thinking about just moving to a way so the users can have the option to select multiple events at a time rather than just, you know, if they wanted to select multiple events, the option that was in the UI earlier would just all events, but that was not maybe the case that we wanted. And we wanted to give users the ability to select events on here, just clicking on them, whatever they want. Nice. It looks good. So earlier there was also the all events option, which is still a part of it is inside the code, which I will remove, but for the sake of putting it into the Jenkins contributor summit and the GitHub at that time, I removed the all events option from here and also the config part of it. So, you know, by default, all of the options will be selected. And if, you know, over here, all the events will be sent. So we can also try looking at how this is going to look like. I'm going to save this. And also the default equals true. It wasn't working on. Yeah. Okay. Anyway, so the default equals true, it wasn't working inside of inside of Jelling files or what I did was just do like equals true inside of. Do you guys see my code or VS code on the right? Yeah. So, since all events were selected, the two top events are event, a job created and job updated. So obviously they are not sent because that didn't happen. But I can also show how they're going to look like. So I know the last time we talked, we were looking at the, you know, the type was just earlier, I just had like the type as Jenkins. Yeah, because this was like, but then Mauricio also suggested changing it. And then I also looked into events from Captain and Tecton and Google event. Again, the type was inclusive of the sort of the URL of where it's originating from and the object. So here it's like the queue, here it's job. And then obviously the type of events, mentoring, waiting, queue left, and they're happening in a sequence. So are you going to give job started, job completed, job finalized. And if there was a job failed, that would be emitted besides job finalized. So if the job had failed, there would be two kinds of events, job finalized and also job failed. And I can also try to add it in this. So the job updated event and similar I have a computer added and computer, I think failed event, but it's in inside of a clone copy that I have because it was a bit different. And I did not want to change a lot of things over here until I was sure that it is working. But some changes in terms of the jelly, you know, I had tried a lot of things with jelly when I was trying to do sort of a repeatable with what I have. So a repeatable here would have looked like, so a repeatable would just be this, but this part starting here to the all the events that would be inside of a repeatable. But that was not working. And then I also tried doing other things like putting this entry fields inside of a different file than the cloud events, global config. So everything, the everything is inside of the global config right now, like all of the events, the getters and the setters, the data bound setters, and also logic to make sure that, you know, since I'm using sort of like an event list to so all of the events, whichever are true would be put inside of this list of events. And then inside of stage is where we would be getting all of those events and then processing it as should this event be sent over. It has this has this user selected this particular event. So all of these configurations for the kind of events, you know, created, updated, although doesn't need to be here right now. But I'm not going to comment about just yet. And other other configurations like same type and sync URL are also inside of global config. But what I had initially was something like pilot and point and the endpoint class was was where all of these events were present and events like created, updated. And this basically had endpoint inside of it, which was being configured in the jelly file. But that was also not working. I can go back is to show how I was looking at it. Well, this is the first folder class which I closed, because it was really different from the other one, which is in main right now. So I had something like endpoint list and endpoint and this was an entire class, which was inside of repeatable, which was working. So it was something like we have the endpoint list. And this is going to be coming from the end points variable and the end points variable was basically just a endpoint instance inside of the global config and the endpoint instance was nothing but just it had the list of events and it had the sync URL. But it seemed to not work inside this jelly file. So I have to move all of this in the cloud config or like the global config. So if you if you guys have any ideas on, you know, because I think this is not really clean and we can make it better and I really, really tried with jelly but there were it was showing up in the UI. But the only problem was it was not saving across applies or saves in the UI configuration. So I had to configure it this way. When I had anything looking like F entry, maybe feel equals. And then inside of this, I had something like F checkbox value. It was value exactly. But I I looked at other config files from different plugins. But it wasn't working and I'm not exactly sure why because I did try doing it the way other plugins. No other plugin had this sort of inner class configuration in a checkbox inner class hasn't, you know, a cloud events global config holding a reference to an inner class like endpoint and that being configured through jelly. So they didn't have exactly that but they had a way of accessing like in our variables and in our just maybe like getters and setters. So I don't really know. But you know, if you feel like this is fine then we can go ahead with it. But I honestly don't really I'm not really impressed with how the global config is right now just a lot of just a lot of content there. And also this this is sort of the functionality which I have to keep for making sure that the event as like a person is on the UI and as they uncheck the the checkbox want to make sure that it gets deleted from the events list. Do you guys maybe have any thoughts on this? Sorry. It's totally okay if not we can move ahead with how it's looking. I mean if it's if it's working I would just just move on for now because the important thing is to be able to easily configure it and you know not spend too much time on it. One thing that my this is totally future but if you look at like for instance the thin backup plugin it doesn't it doesn't have like global config like this. It has kind of its own separate app where it manages settings and it's a better user experience. I'm not suggesting you move to that now but that potentially could be something we look at in the future if there's time. It's just it's just better because all of its settings are on one screen all by itself rather than the if you have a lot of plugins installed the global config is just it's a it's a pain. I use the global config for some of the the plugins that I created to it. It just it just like it just adds to the mess in my opinion but again I'm not suggesting we change it now but just something to keep in the back of your mind. If you have time later after after we have all of the like actual cloud event stuff working and then she suck his nose. We can't think like I'll be really interested in looking into it. Can you maybe send a link to that in the back? Yeah. And also Jeff your idea on interfacing the common methods inside of like outside of different models you know the model and job model to sort of get the source and type for cloud events. I think it worked really beautifully. It's a lot more cleaner and I think you know this piece of code it's a lot more also elegant than like using all those eliffs. It would have gotten very very huge because there would have been different event listeners of course. So I think it's good. I'm glad it was helpful. Yeah so so some of the changes over onto tasks just the unit tasks and some changes to just how stage was running to sort of make it a bit more cleaner I guess. And I'm still as I add the fourth event listener the computer listener I'm thinking of dividing this a stage between different classes for each listener each. So like a job listener would have a stage as we talked about last time because it's maybe it's going to just make more sense when it's divided and it's not it's not going to be super confusing I think. Yeah those were the changes for this week again as I said not not a lot of work done but but I'm hoping that starting this week can get more accomplished and then start doing more work in terms of writing more tests and also just writing the implementation for Jenkins as a sink which I've started looking so I think it should be good. This is a great start. Thank you. Good work as always. Did you have any any additional questions on how to move forward or are you comfortable with what you need to do next? I think I'm pretty sure on what I need to do next but maybe one question would be one we are implementing Jenkins as a sink. I am guessing that like the project it just needs to remain inside of this as like a global config would I'm just thinking would we need to have any UI input when we're talking about Jenkins as a sink like would users need to configure anything like okay here's what we'll be sending events to you like Jenkins will be receiving events from so and so like this particular URL or this particular client or is it just you know no config in terms of no code or no config in terms of the UI but Jenkins just receives a certain event it gets going to parse for whether it's a structured kind of a cloud event or a binary cloud and then depending on that event metadata it can extract the type and then trigger that particular the particular action that it needs to do. Did we talk about authentication whether we want to make sure that we we trust the source that's sending us events or is the thought just anybody that has the URL can send them? I don't think that we talked about it but I think that's a very good idea and also like a very important implementation I think like what we initially did was we said okay let's start with Jenkins as a source so we did not go into a lot of conversation with Jenkins as a think but now since the time is approaching to implement it I think we are starting to think so yes thinking about authentication or whether or not this particular URL or this particular just project can send us events or not I think that's really important and I think I should start looking into. Yeah I'm not sure what what that what the options are for that that I mean that that's the only thing I can think about the top of my head that might require some kind of UI there might be other stuff but nothing comes to mind I don't I don't know that we we need well I mean if we have depending on how how flexible the authentication is that it might include you know permissions about like types of events that can be consumed or something so I don't I don't know if some sort of web hook interface would work here or whether there's better technology this is a little bit outside of stuff I've worked on. Yeah I've been thinking about just UI changes too and like what I was maybe thinking of is that Jenkins yes we'll need to see is there's certain because you know the last we were talking and Mauricio mentioned that it's the duty of the sync to decide whether or not the sync wants to work with a certain kind of event so maybe that's um I quite hardly want to say something. Okay that I was thinking this my impression is a sync job is to determine whether or not they want to receive the that a sensitive scribe to subscribe to it but beyond that I don't know how much I don't know how much control or or programming that happens I think it's like you subscribe to the events that you want to be in and then this goes down the chain that the events themselves are omitted and then there's a question of who subscribes and then each person who subscribes or each service or sync that they have their own like service will decide how to handle that the message from the event the data from the event. Yeah that's that's probably all that's required for this I was just thinking about like like in GitHub with their their web hook UI you can grant permissions to different types of things but but just because it's not clear to me that we need that here um just just like like you're allowed to send me an answer or you're not it would make me happy. We can think more about it and start with a basic implementation. Yeah. As we move forward so do we still like think that when we are saying that the sync decides what to do with the event do we if all of that is it going to be inside the logic or should we move some of that to like the UI code so UI has a bunch of events for example also the above sent me this the event like vocabulary which is going to standardize sort of what each event means and what each event should be doing so if we're thinking in terms of that maybe when someone says okay resource has been created what Jenkins wants to do is run a um a particular job so um of that not maybe not the URL but maybe just the host of that sync or the source not the sync I'm sorry the source which is emitting the event and then the the user can also select what's events are coming in from that particular source so our logic will only work on doing that particular or just emitting those particular actions or just doing those particular jobs that it needs to do when it's receiving those particular events right yeah I think that sounds quite good our can you think of um actions that Jenkins could do other than running running a job yes actually that was um a conversation that I had in the Jenkins contributors summit as like you know when we're thinking of actions it's more just like when I am thinking of it it's more like you know a running job or like running uh start or complete or just end the job or something like that but then I uh mentioned to above that we need to think outside of these actions and maybe think of again going back to that vocabulary we need to think of running some standardized actions like starting a new note starting um or something like that which is just outside of the general scope when the events are just standardized as a the vocabulary has certain events like I don't exactly remember right now but it had something like resource created and resource updated so what maybe what we might want to do is have a job which is going to test the availability or just test the stability of that particular maybe project or that particular you know something similar to that so I think that having part of it moved to the UI and just selecting which event slash events are emitted from that host or from that source might help us reduce some complexity in the logic since we'll not be putting in a lot of okay if event is this and this or this and then do this and maybe that's what I am thinking but I'm not sure if that's the right way to think and this maybe is something that I will need input from the entire like team and hearing your guys's idea on what you think the implementation can look like and maybe in what the end product is just going to be a mixture of all of our ideas yeah I like I like what I haven't spent much time thinking about this but I kind of like the direction you're going from what you've said I mean you get a particular event you might want to run a job and so there's other things you might actions you might want to take you got a particular event you might want to create you might want to start a note or stop a note or something you could maybe there could maybe be an event that like creates a user so there are maybe some other actions that you might want to do so I the flexible model makes sense to me maybe I'll also like start researching different actions again I'm still not really sure about I said like no off actions as a Jenkins user but I need to go and look more into the documentation is just understand the scope of different actions and what they all tie into there is also a Jenkins pipeline authoring sake which is different but they might very well have ideas and all the different things that might be happening that you could be doing with a pipeline you know this this type of question I'm just thinking reading the docs is very good and but it can be but you know you might be interesting for you to ask a wider range of people as well um right sounds really good and that was the only question that's in my head right now um and as more pop up I will put them in the chat just a heads up that the first and only evaluation the midpoint evaluations for this summer's GSOC will be between July 12th and July 16th and it basically is the mentors and students submit their variations of one another so the mentor team will submit one and then you submit one and what we have always done with the Jenkins GSOC is we do student presentations at this stage and this happens at a Jenkins main dump which is especially planned for this as we are taking part in GSOC this year under the CDF umbrella we will likely do this under the CDF foundation so there will be a CDF type of media but it will be the same idea where all the GSOC students do say a 15-minute presentation and then five minutes Q&A and we have six so we're going to be about two hours but so a couple questions we are thinking that the possibility of having them pre-recorded or live is a good one usually they were live but just because I don't know I think pre-recorded can be quite good especially for asking for only 15 minutes so there's that and then the other thing is so the week of the evaluations themselves are between the 12th and the 16th but we can do this presentation either before during that week or after and I just wanted to ask you Triti if you had a preference I can do before so like when we say before do we just like mean the week before I can maybe extend a recording you know like the week before maybe mid-week like a Wednesday or Thursday the staff sound okay yes so yes so in which case if you if you want to do it recorded that and that's absolutely fine and if you send it the prior week so before the 12th then we will likely have that media of course after that so it will be just be a matter of gathering and but that sounds good to me so then we'll either run the meet-up itself either at the end of that week right before evaluations or during the evaluation week does that sound good is there is there anything happening that week that would make it hard for you to attend I just wanted you to be able to be part of it you know if you have any family events or anything um no there's nothing that I know of that's happening and I should be available and I also found really exciting so yes okay good excellent and we'll be sending out more information about the exact time of it I just have to discuss with everyone good yeah really looking forward to it should be lots of fun the presentation is always good and it's amazing the work that's being done so and your work is awesome so I'm very excited for your presentation um but I really only have like Jenkins as a source um done right now I'm not really sure if this is enough or should I maybe like add bits and add since you know we are talking about starting going into Jenkins as a sink and I can see what gets done by that point and put that into the presentation if it's looking okay of course but what we have right now is that okay is that enough yeah it's great your work so far has been amazing you you're doing sick and I'm sorry you know it will progress in the next 10 days too but what you've done so far is from classic yeah this is one of one of the best projects I've been on I mean I've been I forget I've been on like just just a few two or three but just been really easy and do lots of work and and really keeping contact with the mentor so you know and I had somebody that just would sort of disappear and and didn't see them for a week and that and um but yeah so it's all good thank you so I'm excited for that um and okay so the recording you said 15 minutes and that just it shouldn't be like demo plus also like talking about the project in general like the collaboration of say Jenkins and cloud events and how that's going to help interoperability in general and also just extend you know to send you know the whole idea of cloud native and standardizing events across different systems I'm just thinking of thinking of that and I think both is okay yeah I think that sounds really interesting and it makes the subject more accessible to people who are maybe not looking in the space and so kind of give some context for them which and it gives a sense of why this is super interesting which is always nice but make sure you have enough time to present the work that you're doing because this is really for you to share you know your work as well but it is good to put context in if you have time yeah it sounds good thank you thank you very much so great we can wrap up the meeting now and see you all in one week's time but we'll be in contact on snack thank you