 So there's one thing I would like to discuss is how like in what are places can we use the cloud events and kind of like start thinking over just how the plugin can be used. And what all stuff needs to be done. So I feel the draft isn't complete in a way because there needs to be there needs to be a repo and I saw your review with the new befriending issues like without a repo and some understanding there can't be any issues like even with some code. So you mean linking to the open newbie friendly issues. Yeah, that I in the Jenkins project are the issues aren't our links in the in the JIRA so not as much GitHub issues, but that's that's the way They are handled within the Jenkins project. So these newbie friendly issues would be related to the plugin only or any newbie friend. No, those are just Jenkins newbie friendly issues. So I couldn't think of I didn't have the top of the mind and newbie friendly issue that would be helpful for someone trying to get grips with cloud events for Jenkins. But we can we can look for some of that might be a little bit harder to find your can I can I ask you about your idea of having of looking into what the cloud events would it would contain like what metadata they would contain. That's pretty interesting. Are you are you following sort of the definitions and proposals that are coming out of either the CNCS cloud events work or or that's being done within the CD foundation with the interoperability sake and cloud events that's becoming its own. I kind of missed yesterday's meeting because I was quite late in the evening, and it was, it was, it was much earlier. So I, I haven't been able to follow that but my, the idea I was having about the metadata with Jenkins was around how tecton kind of handles them. So my entire idea was like how tecton does it. So once, once someone subscribes to like cloud events for Jenkins, they would get to know if a job has been started. If it's failed, and like, and things, things like that. So probably this would mean that the, when when someone subscribes, we should be able to give the data for the, what all jobs they have subscribed to, or even if, like, this, this, these are the nitty gritties we need to kind of discuss and figure out. So this is the discussion I want to have, like, how does, does the user subscribe to a particular job or do they subscribe to Yeah, basically a particular job. And once they subscribe to it, what all stuff goes through to the other end of the cloud events pipeline. Like, this is what I was thinking about. So we probably need to make a table of the, what the metadata looks like. So this could be an action item I could, I could take and make a draft table for this one. Something like io.jenkins.job, probably job name.started, true or false, something like that. So we could have this. And so this thinking, this makes sense, right? What do you think, Eric? Yeah, I think that would help to kind of sort of fleshed out a little bit more. Yeah. I've got a few, like action items on my side. I need to, I need to go and like, yeah, sign up to the SIG for cloud events and do a bit more research into it. Before I can provide any sort of, yeah, value in my review, really. Probably next week, what we can do is we can actually do action items for like a bit of research and then we can kind of brainstorm over what all stuff can go through. So we could do that. And so this would be helpful when creating like event listeners in Tecton, then like hooking up the Jenkins cloud events and Tecton cloud events like easily in Jenkins itself. So something happens in the Jenkins job and probably all of that is that stuff is propagated to a Tecton task run. So looking along those lines, if we can kind of have a chain of things running at some point in time, but okay, so let me just get the dock. Vibhav, you just said that a Jenkins job will have a corollary of some types with a Tecton task. Is that, is that, which was I understand correctly, and then you want to compare the metadata between them? So, not corollary, I'm not sure. What I was thinking was the cloud events that Jenkins will create, that cloud events could be listened on by Tecton and that configuration could be done through the Tecton client plugin. So that, you know that Tecton task run listens for that cloud event of Jenkins. So this is what I was thinking. Okay. So I'm just thinking out loud. But, but we should, before we go there, we should just focus on what cloud events can do and kind of figure out the user stories around them. So, once that is done. So initially what we'd have to do is we'll have to play a little bit with the cloud events SDK, make something simple, and then figure out how that works with Jenkins. And if we maybe enable cloud events for a Jenkins job, there should be probably be an endpoint, like endpoint, one, something that can be subscribed to. And this and whatever, whatever other tool is there, they should be able to like listen for events for that endpoint. So this could be like a first prototype that that could go about so that we understand like how cloud events work. And then for the GSOC part itself, I want to ask like how do we, I've never done GSOC before or like been a mentor, I've seen like how it goes about. So I'm just, I just want to ask like how, how do we, how do we guide students to do particular things like how do we figure out what they can do and what we should like help them with and basically just how do we guide them or give them things that they can learn. Hi, I'm going to share your, I'm going to share in the chat right here that Jenkins guidelines for for mentors so just give you a lot of information that you know has been written over the last couple years. In terms of guiding students, it is it does get pretty, I would think pretty individualized in terms of the projects in terms of the mentors background and then most importantly in terms of the students background and what knowledge they need to gain in order to engage with the project idea. So, yeah, that leaves some room for creativity for the mentors. Okay, that's good. Okay. So I'm thinking. So for the cloud events plugins should we bootstrap the project before starting it off or do we make them start from scratch bootstrapping would, could help quite a bit in helping the student to get started. Yeah, I think that's, I would say that I think that's, I think it's probably a pretty good idea. Just going on my experience of getting repos created and set up and things like that and like a basic build on day one that can take quite some time. So it might make sense to do that. I think you the students would really appreciate it. And in addition this summer's G talk schedule has been altered from how it was traditionally done, and it's a shorter coding period so you know if you everything we can do to help the students like hit the ground running for their coding phase would would be really I'm sure they'd appreciate it because then that will enable them to do more substantial work for the times that they have. I remember I was, I did ask a friend about it who did it before like it was three months and now it's a month and a half. Yeah, it's basically been caught in half. So it's a lot shorter in practice. It's more because the students start engaging now learning about Jenkins in general and thinking about what they want to make a proposal on then they formulate the proposal that takes some work and engagement and then if they're chosen there's a community bonding phase which is a number of weeks. So, at which time they're kind of like getting ramped up. But nonetheless that shortened full time coding phase is is is a limitation we have to deal with this summer. So everything we can do to help the students is great. Actually, to start from scratch would have been nice if it was three months, but something like tech on plan plugin, which is a little in still POC phase and there's still a lot of stuff we can do. Yeah, that's that that makes a lot of sense. Yeah, then we'd have to bootstrap the project then because one and a half month is quite, I can't imagine doing anything and one and a half. Yeah, it's quite a short time. So yeah, I think so when we bootstrap till what extent should we bootstrap it. Should we should we kind of bootstrap the cloud events SDK and the metadata stuff. Yeah, I would have said I think if it's a plugin that we're creating, I think if we can have a kind of like a skeleton of a plugin that does. Yeah, doesn't have to have too much in there, but as long as it has a Jenkins file that's doing a build and some kind of tests and we have the ability to create an alpha beta release or something like that. I can early release and people are able to at least, I suppose, install the plugin, even with a few manual bits and bobs, but like, there is a bit of a build and a bit of everything else going that I think that's good. I don't think we need to get too much into the internals of how the plugin will work. It would be nice to be able to, you know, clone the project, build it locally and easily push up a PR and have valid automated feedback on that PR for when they ready for when the sort of students start on this, especially if we're going to go a month and a half. Yeah, that'll be good actually. I think, I think then over the next week, this would be like our main agenda to figure out how to kind of the extent of the booster probably be around with cloud SDK. Cloud events SDK. Okay. Yeah, that makes sense. Okay. I don't know. I don't know anything else to discuss about the cloud events plugin. Maybe, maybe I have something in on my on your mind. Nothing on from my point of view. I need to go and do a bit more reading about this and I need to look at the proposal in detail. Now we're going to schedule some time probably later on today to do that. Similar. I think this looks good. I think we have a number of action items that I've put in our meeting notes for us all to look into and and consider. So hopefully we'll have more on these next week to circle back and discuss. It's pretty exciting. Hello, Sega. Did you have any questions? No, no, I'm just listening. I'm just trying to understand so that I can explore this one also and I'm a little bit curious in local and communities and cloud event and this project is related to that. So that's why I'm just Do you have, since we're all here on the skull, we could we could find this for you. Do you have a good idea how to get started in doing the research that you need to do for understanding more about cloud events. Um, for now, um, um, last time, um, my mentor me little bit. He said that first try to understand Docker and Kubernetes. So, um, but for understanding Docker and Kubernetes, I need to know the rest APS and back and stuff also. So this week I learned about MongoDB and express and node and all the stuff. Now I will try to, um, now I will, um, integrate Docker with that and then further I will move on. Hopefully, then what problem actually we are solving. Yeah. That's good. Yeah, sounds very good. I'm glad you're having a good time with it. So, um, about, so if, so about the technology and plugin, I, I am still thinking so I didn't end up getting to the draft because I was still thinking like what will, what can be even done about the client plugin. Like it's, it's not, it's, it's in a phase that it's a, it's a, the POC is done and there are, there is a lot of stuff the students can actually do. Um, if, uh, considering the timeline that is there right now, initially I was thinking, uh, maybe the three months, uh, would, would be a little, uh, too much and maybe the, uh, maybe the project might get over prematurely. So I was just thinking if it is, uh, like, how do we handle that? But I think in the scenario that we have right now, it makes the, the tech contract plugin, uh, kind of fits very well into what can be done. So, so what I'll do is I will create a draft for it and then, uh, share it, share it with you guys on, on the GSO channel and also, uh, on Gitter channel. So I'll do that. And anything like in particular Gareth, like, uh, you would like to, or, uh, you have any ideas for the client plugin? Like maybe there is that one feature we would love to see after that one and a half month of coding, probably catalog support or something. That would be very cool. Or like dynamic tasks that like, like picking up tasks, like dynamically from the drop down menus for a task and stuff like that, uh, that is on your mind. Anything. Um, yeah. So I've been on your recommendation from last week. I've been looking at the tectonus code, um, sort of tectonus code and proposal. Um, and this is sort of a few of them out there and a few different pox from what I can tell, but that's the kind of, I suppose that's the kind of thing that I was envisaging. So not so much the UI side of it or the UX, but more of the, um, yeah, like a, like a dot tecton folder or something where you can automatically pick stuff up from within your Git repo and have it. Um, so however the client would work, it would need to pick up the particular one and schedule the pipeline run with the right parameters. Um, it's, it's a bit hard to say because I think at the moment they're just proposals. So I don't think there are any sort of like concrete implementations of how that's going to work anyway. But, um, that might be a good. I'm just thinking so would Jenkins be like an intermediary between tecton when we do this? Yeah, I mean, that's the, that's kind of how I was thinking. Um, we have, we have users that have, you know, large Jenkins installations and lots of builds and they want to want to go all out on tecton from day one. So providing like, you know, whether it's the ability for them to view all their jobs in the same place and have a, you know, a Git repo that is listed and looks, seems to be configured in the same way. And, but when the job is run, it's actually kicked off as a tecton pipeline and that could be you need a Jenkins file and a tecton folder inside the same Git repo to be able to do it. Just have a message. Thinking like it's, it makes more like I was thinking if like if we could do something like have a Jenkins file only, but make it run like tecton DSM. So that, that seems, because if we, if we do like a dot tecton, the tecton as a code developers, they've already kind of, I'd say monopolized on the dot tecton part. So, I don't know, maybe, maybe, or. I mean, the dot tecton is quite nice because it fits with the, you know, the dot light house for Jenkins X and dot GitHub and all that. Well, of course, if we could have this. Maybe it is just an integration between the tecton client plugin and the tecton as code piece, like have the ability just to do that kick off. Maybe, maybe that that's just kind of simple as it needs to be to begin with. So, how do you see the tecton as code integration with tecton client as a plugin? I'm not, I'm not sure yet. I'm thinking it's a, it's a good idea. It's a good idea. Yeah. It probably needs a, because the scope of the client plugin and the tecton as a code. I'm just thinking how that will work. Can, can you share the tecton as code, like links to the tecton as code in our chat and I'll put it in the next. That is the tecton as a code repo. Okay. So this one is created is being created by one of my colleagues and he is bootstrapping it as well as making it production ready. And it's, it's doing actually quite well. The only thing we're waiting for is to get this merged into tecton. Like the tecton CD. But it works very well actually. And it uses the tecton dashboard to see all the tecton tasks running. It's quite good. Nice. So probably what we could do is we could read the tecton as a code code and then understand like how it works and probably recreate the experience. Yeah, because this is Python isn't that I believe. Yeah. Yeah. So this would be recreating the experience in Java. Yeah. So when you say recreating the experience in Java, do you mean recreating tecton as code doing a Java version of this and then integrating that with. Is that what you're referring to? Did I understand that correctly? Like, yeah, what I did for the tecton plan plugin was kind of similar. I read a lot of the tecton CLI code. And I basically just understood how a lot of the stuff work there. And then I just replicated that entire thing into a Jenkins plugin. So including like how getting the logs for the tech tasks and all the simple stuff also like it worked out pretty well. Yeah. So, so we could probably do that. And we just need to figure out if it makes sense to do it, or if it if it is even possible that would take some reading but probably we could keep this for next to next week. So, because this this week seems fully fully of full of cloud events. So probably will set it for next next next week. So so for them for our next meeting we'll focus our research on finding doing doing these action items on cloud events. Following week we'll focus a little bit more on the tecton client plan. I think that's probably a good way to break that up. Yeah, that sounds good actually. So we could next week, as you said, we will discuss cloud events and the extent of the prototype, as well as that our students can do for cloud events plugin. And then post that we can discuss the tecton client plugin and what needs to be done for that and maybe a few issues that students can start picking up for the time because there are actually quite a lot of issues that students can just start picking and playing around with it. Probably we can just. So I'll create a draft and share it today. After this meeting. So, I've just reached out to the James is on the Jenkins X dev list to see if to see what they're doing with the lighthouse so when they have something that is very, very similar to the tecton is client tecton is code. Peace where it reads everything from the from a dot light house directory and the reason it's called dot light house is just because of that's the name of the component inside JX. But essentially it's just a, it's a dot folder that has a list of tasks and gamma files or tasks and pipelines or whatever and they get applied. And sort of run what I'm asking them is, are they doing any manipulation or rewriting or, you know, enhancements of those files before applying them inside JX. Because I think that would be. I think it's quite, I think it's very similar. What we're looking at doing with pretty much looking at a job implementation of that piece. So I can run from inside Jenkins. So, yeah, that would be that is that is actually what we're looking at. What would be very interesting is to have existing Jenkins users. I think it's a Jenkins file with some simple DSL for tecton. And they can just, you know that they can just like they wouldn't even have to think of new semantics, because I think there is this kind of schizophrenia involved with, you know, working with new files. Oh my God, it's a new file. I don't want to deal with new files. Like if they could just like use Jenkins files and then probably just write some simple DSL like create task colon and then put like task name and give whatever. Yeah. And I think you've got, you've got people that will, they'll want to do or recreate certain parts of that pipeline as tecton. There'll be other bits of the plugins that they'll be using, but just make absolutely no sense to convert. So like, if you're talking about liking, like maybe archiving J unit results visualizing them in the UI, maybe you, you have the ability to run the in the Jenkins file, you could run the tecton part of the pipeline first and in the end stash this information somewhere store this render this run another plugin on top of that. That may make sense. Yeah. And this would integrate like very properly with their old, like the old pipelines that they have. Yeah, otherwise, it's the idea of like completely repurposing your CI for a new one, like your pipeline for a new one. It is taxing in a way from user's perspective. Yep. So actually next week we could actually think more about how this could be done. We could focus on DSL for tecton in Jenkins file and also look at like dot tecton dot lighthouse probably we can have like a session and understand like which one, you know, work best for what we need. So I think that we could go to that. I think that would be really useful. Should we aim to have this the session during this meeting. I'm just thinking it would be kind of fun to have time to try and pull in one of the changes. I don't know what the schedule is. To pull in who? Either James Stracken or James Rawlings or James or James. Okay. I can, I can bully one of them to attend. I'll bribe James Rawlings with some wine. That sounds nice actually. We can, we can take, we can ask them, maybe it would be nice actually if they could provide the perspectives. It would be pretty good. Okay. Um, very nice. Any, any, any other questions or action items or issues to discuss for cloud native in general or, or for GSoc, but, but any other cloud, it doesn't have to be. Not from my side. I just, I just want to start attending the CD foundation meetings a lot more often. Yesterday, yesterday when I missed them, I was just like, no, not again. After the timing change. So, not, not, not anything in particular, I think we've discussed and have a lot of action items actually. Yeah. Yeah, we do. Great. I am so happy we are, we are moving this work and parceling it out for GSoc students because I think this is a really exciting area for them. So, Is that, is that the sake? Is that the events in CICD work stream? Yes. But that is that is it still being called a work stream? It's really on the cusp of becoming its own sake. I think it's just, just, I mean, yeah, I'm, that's what it's in the CDF. That's what it's in the CDF calendar at the moment as that. But I think the next one, there isn't one next week. I think it's every two weeks. Yeah. First of February. Yes. Let me pull that up and add it. I have so many event calendars. It's a bit much. Okay. I'll put it in the chat notes for the CDF event calendar. So you all have that. And I'll put it in the notes for the meeting as well. Guys, where are you located? Where are you working from? Kongar. I am based in London. And I'm in Northern Ireland. Okay, that's nice. I'm based off of Bangalow. You're, yeah, you're a totally, what time is it right now for you? Just so I know. It's better. It's, it's eight, seven. Okay. Okay. So it's not, it's not, it's not great, but it's not terrible. I could see how, yeah, two hours later was much worse. Okay. I'm glad we moved this meeting. Good. Excellent. I've just put the link for the CDF at the top of the meeting notes, the calendar. That's kind of a funny looking name actually. Cool. Good. All right. I think we have covered a lot of ground. Today's meeting. Thank you all for being here. We have all of us a lot of action items to do, especially Viva. Thank you for leading these two GSoc proposals. They're both super exciting. And I'm really glad we are moving this cloud made of work and making it available for students to engage with. So, excellent. Thank you all for being here. Do you have any last many questions ago or anything that we can help you with? Actually, no. I'm just trying. Yes. Good. Good. We all are excellent. All right. Thank you all very much. We'll see you at the next meeting. Have a good weekend. Bye. You too.