 event sourcing and event notification and CQRS and other one is event state transfer carrier, yeah. And yeah, and Git is based on kind of event sourcing, which after, I mean, learn about it, it sounds like amazing. I don't know about this, like how it works. Now, actually, no, it is based on event-driven architecture. It is really interesting. I look forward to watching that talk a lot, actually, because I think the section on client plugin is really interesting. And then all the cloud events, like the cloud events plugin is really interesting. And then there's a number of areas where cloud events and trying to standardize on cloud events and CI CD pipelines is really coming forward. So it's helpful for me even to have this resource. I'm quite excited, actually. Thank you. I'll just put it in our meeting notes here. You have any questions on the work you're doing for GSOC? Is that good? Currently, no, but I'm just exploring about the project itself. Yeah. Hi, Vibhav. How are you? I'm actually Vibhav. This is really interesting. Sagar has just shared a link to a talk on giving some context and better understanding around event-driven architecture, which is one of the things I had really... Which is actually Vibhav shared to me. Which actually Vibhav shared to me. Oh, he shared with you. Okay, perfect. Great. Because that's what I wanted for your GSOC. So I created a PR just right now for study links for the cloud events plugin and I opened the PR to the idea doc. Perfect. Okay, I'll get that merged and that's great. That's really, really good. I also just opened a PR for the proposal for cloud events plugin. Sorry, I mean Tecton client plugin. So that is also up. I did a bit of brainstorming over the week. Not too much, but of how this Tecton as a code could... That format could help us. I got a bit of understanding of how the Tecton as a code worked. It's actually pretty straightforward and most of the action items I think are almost covered. So for today I just want to get the discussion ahead with Tecton client plugin maybe. So we could set in stone what would be the aim for the GSOC project. And also probably if you could discuss the timeline for GSOC because yesterday I looked at the timeline for GSOC. It seems like it's close to three months for coding. Yes. So GSOC will be over a 10-week coding period, but the amount of hours demoted of students is greatly reduced this year. So it'll be 175 hours, which is roughly half what it usually is. And that's just kind of acknowledging that this year is very different. And I think the GSOC organizers wanted to try something different that could make the time of GSOC more flexible for students and mentors. So the idea is that there isn't a lot of flexibility built into that 10 weeks. So if students have exams they can take a couple weeks off for exams. If they have a personal event or something they need to spend time on they can do that. And the idea is that students and mentors would work together to decide when would be the focused work during that 10-week period. The only constraints on that are that GSOC does want to see a halfway point. They would like a review of the students work and they would like roughly half of the work to be done. So the mentor and student can't decide to basically end load the work. So the last five weeks all the work would get done and that wouldn't work from GSOC's point of view. But other than that constraint there's a lot of flexibility within those 10 weeks. That sounds good. Okay. I was under the impression that it is week-based and I didn't consider it to be hour-based. Then that makes sense and there's still a lot less of that. Yeah. And I guess from a mentor's perspective it makes sense to think of it week-based because you're probably thinking I'll see my mentee once or twice a week. But maybe some weeks you won't. And I guess as a mentor too you can say look I have to do this thing this week. We can't meet this week. So you have some flexibility as well. But yeah. I think that 175 hours is important to keep in mind when thinking about what your student will realistically be able to get done during that time. So really with scoping the project. I'm trying to. That would be the thing that we would be trying to optimize for them. Yes. We will. I'm just pulling up your excellent your proposal and then I'll share my screen. Can you see my screen? Yes. Okay. Thank you. I can also see that I need to fix some links. I'll just do that. Okay. That's fine. Great. So right now your scope is the project requires the student to start with plug-in development from scratch and then work with understanding how to use the cloud events Java SDK to create and read events. Okay. And the student will start with work on understanding Jenkins plug-in development. Yes. Okay. One second. I think I copied the wrong stuff. Okay. The same sentence is like twice on that. Yeah. Same thing is twice. Yeah. So let me fix this. So I need to fix this and the links. I didn't copy the quick start properly. Let me fix this. That's fine. So yeah. Like when I started with Jenkins, like Jenkins first I like made my like scratch plug-in using tutorial on Jenkins and today I'm just playing. First of all, then I learned about this even driven architecture and today I'm playing with the cloud cloud events on Java SDK as per docs. Yeah. Awesome. How are you finding the cloud events Java SDK? It's on the doc. If you see it's on the doc. Yes. No, no. I mean how are you, how is your experience with it? Oh, yeah. So I find one discord server of Java where I'm just posting my portion and they're helping me launch. But speaking of that, I never worked with networking in Java. So it's also new for me, but it's interesting because I love Java and there is Java networking. Good. You're in the right project then. Okay. That's a good start. The cloud event. So community is really good, even though I haven't interacted with them enough. They have discord channel. No, no, no. That's just a Java server. I mean just a normal Java server from discord, not from cloud events specifically. Java server as in you mean you created a Java server which uses cloud events? No, I mean a community of Java developers. Oh, okay. Oh, you're talking about the community on discord, right? Yeah. Yeah. That's what I'm saying. So they are a great community and probably we'll interact with them at some point to understand some best practices for cloud events. So what's wrong next? Is there is any, by the way, is there any guitar for cloud events? Like there is one for Jenkins. Is there is a guitar or any specific group? I didn't find any link in the docs. There is no guitar for cloud events plug-in right now. No. There's the cloud events. There's this thing has a guitar channel. Yeah. So cloud native sec would be where we could discuss everything. Okay. So can I get that link? You're already part of that, I think. Let me check. Let me send it to you. And Vibhav, what do you need from us for this proposal? How can we help you narrow it down or define the scope? Yeah. So for this proposal, yeah, I was thinking of how we could narrow it down earlier this week and later today, not later today, early today. So I was thinking of focusing on one particular aspect of the cloud events plug-in and this part, we've been discussing for a long time about the DSL bits, the dot tecton folder bits, which can be used to trigger tecton pipelines through Jenkins. So I was thinking of narrowing it down to the DSL for tecton and having dot tecton folder support. So what tecton as a code does is when a PR is opened, it checks if there is a dot tecton folder. So it triggers, first of all, what it does is if there is a tecton trigger enabled for the repo, the trigger will trigger a tecton task which will check if there is a dot tecton folder in the repo and then it will apply all those yaml, the pipeline yaml, pipeline run yaml, which are needed to run the tecton pipeline. So I was initially thinking that it doesn't ask straightforward, but turns out it is pretty straightforward of how it works. What we could do is we could keep the dot tecton folder, but in the Jenkins file, we can provide parameters for what will actually happen. So we can provide parameters with that, that's something we'll have to figure out, but if we narrow it down to this bit for the tecton plan again, I think this will be pretty nice. So basically, we'll be narrowing it down to the DSL for tecton in Jenkins file. And in the DSL, we say something like tecton bracket, name of the tecton server, like name of the Kubernetes server. And then under the brackets, in the closed brackets, we say something like push enabled or something. So the tecton task will get triggered when there is a push or a pull request based on whatever parameters we provide in the Jenkins file. This is how it could work. It shouldn't be that hard because it's a simple configuration given in the Jenkins file, number one. Number two, we have to apply the tasks. And number three, the Jenkins would already be connected via webbook. So we could just employ these three ideas and probably create a basic DSL out of it. And this is something that the student could do in a short period of time. Would you say kind of returning control to the Jenkins file after the task is completed? Yeah. Because I was thinking like one of the things that Jenkins is very, very good at is visualising test results and outputs from files and stuff like that. That might be a really nice, you know, you run the tecton task, it produces some, I don't know, JUnit test results, but you actually want to visualise them in Jenkins or manipulate them or stash them or something. I'm quite sure how that would work here. So for me to clarify, for myself, one of the main tasks for the student will be creating a DSL for tecton in order to align tecton tasks with what Jenkins needs. Is this correct? Is this a fair way to put that? Yeah, probably. I suppose the scope of the DSL would, I suppose, yeah, you could say like you want to provide every language feature in tecton away if you've been focusing that from the Jenkins file, but that may not be required for this. You may just need like a limited number of things. I'm not sure what they are yet. Okay. Is this helpful for you, Vibhav, in terms of structuring what you would ask of this student? What I miss. My laptop is two seconds ago. I don't know what you guys saw, my GitHub message I just sent. So I just had to restart. I missed out when Gareth you were asking about would the control be passed back to Jenkins? Yeah, sorry. Yeah, I was asking about whether or not we'd see you pass control back at the end to the Jenkins file so that if there were, after a tecton pipeline has run, if there were additional stages of steps that you wanted to run in pure Jenkins using Jenkins plugins, you could still do that. An example was like archiving JUnit test results or something like that. That'd be quite nice to be able to do. I agree with the DSL. It should be a way to integrate with tecton but not necessarily move entirely because I'm not sure if tecton can do everything that Jenkins can do. There are a lot of plugins and stuff which probably, which have tasks which probably cannot be replaced entirely. So integrating with tecton, this will allow integrating with tecton but not necessarily replace Jenkins with tecton itself. So that's what we should go for. So in that, in that case, in that sense, the control will be passed back to Jenkins file and everything else that runs after the tecton DSL bit would run. We need to define what syntax and what the DSL and everything can do before we, before we actually started out. What do you think like, does this designing also go to the student of the DSL and everything? It could do. I mean in conjunction with the mentors for sure. And in terms of, do you mean when the student is actually doing the coding work or do you mean in advance when the student is designing their project proposal? Both times maybe. I don't know. Probably during the proposal, coding phase. But actually come to think of it mostly during the proposal only. Okay. For the students when they create their proposals, they take, they're recommended to take the project ideas that are listed. Although they are not actually constrained to them but it is generally helpful for them to do so. To take the project ideas and then to create their own proposal based on those project ideas. So focusing on what really interests them. And if they're, they should be doing this sort of as a process with the Jenkins community. So double checking their ideas, getting guidance from future potential mentors, things like that. So if the student is developing this DSL, I think giving them a pretty strong hand and it is great. But it will be done, you know, under, with supervision and mentors and with feedback from the community. Does that help answer your question? Yeah. Gareth, have you worked on Jenkins DSL before by any chance? Nope. No, no, no, no, no, that's not. Would Andrew Bayer be a good person to get feedback from? Yeah, I think he would actually. Okay. Okay. I might try and pull him in then. How soon would his involvement need to happen? Certainly when the DSL's being designed and written, they'd probably be good to get his feedback. But I'm just wondering how far in advance of that we should start pulling him in. I think the sooner, the better really. Even if he could just, you know, get him to be thinking about it a little bit. Okay, great. He may go away and then come back with ideas. Yeah, that's a nice point because I'm not sure how it's been, it may have been a bit of a while since he's worked on something or this. Yeah, okay, great. That's that's helpful. Thank you for doing the PR, because then I can point him to this and then get wider involvement, which is good. Yeah, I will update the SPIA after the meeting. Yeah, there is an OpenShift client plugin which has it soon DSL, which we maintain. But it's been a long time since our red dot code. And there is a little bit of technical debt over there. So yeah, I think getting Andrews earlier would be better to see how we should design that part of the plugin. Because the way we've done it in the OpenShift client plugin, I feel it could have been done better, but it's still like a lot of hard work that goes into creating a DSL because it is an integration layer at that point. For sure, we definitely want it well designed. Otherwise, it's just clunky afterwards. So yeah, absolutely, we want lots of feedback on the design. Great. So I'll I'll try and get Andrews feedback on this and put them in contact with you Vibhav and maybe have him come here and speak if he has time in in the meantime for today's meeting. Is there is there another thing that we should be discussing on this proposal? Another element? So the main thing, the main thing we should discuss is narrow so which we already kind of covered was like narrowing down to the scope of the project. So we know that for a fact that cloud events would be a scope that we should discover and like you should be able to publish and subscribe to cloud events and the scope for the client plugin. Please continue. Sorry about that. Yeah, that's all right. So a scope of the Tecton client plugin would be to in this case would be to okay, give me a sec. Yeah, so scope of the Tecton client plugin for the GSOC would be to create the DSL then. I think that's a good unrealistic scope and would also involve a lot of learning for the student. So what I'll do is I'll so initially I was an understanding like what we should do like last week I was an understanding what we should do exactly and because just creating a design doc doesn't make sense. It needs to have something that makes sense and has a vision. So what I'll do is I'll try to create a initial design doc for the Tecton client plugin and get it with your help. I think we can we can sketch it out pretty nicely what the DSL looks like, what is the scope of the DSL for the student that the goals that they need to reach for the project completion. Because of the DSL we can do a lot but we should know for the project how much is enough. So even something like a minimum compatibility with dot Tecton folder I think is a good place to start. After that we can have stretch goals but I think this is a good starting point like minimum compatibility with dot Tecton folder and doing what Tecton as a code already does but through Jenkins. That sounds like a very good start. So yeah I'm just thinking it shouldn't be no but it will end up being like that. So what I'm thinking is basically like currently how Tecton as a code works is it is directly connected to Tecton and all the task triggering directly happens in Tecton. So the task is triggered in Tecton and all but with this DSL bit what we would be doing is we'd be using a Jenkins file configuring configuring that having a dot Tecton folder or even it should be possible for the user to configure whatever pipeline or whatever they want to do in the Jenkins file itself without a dot Tecton folder. If there is a dot Tecton folder it will pick up those channels from there applied through the Tecton plugin into in Tecton and then do whatever tasks but yeah I think with this it will provide flexibility for the users to use dot Tecton or not use dot Tecton. So if there is a point where there is a user who says that okay I've been using Tecton as a code but I also need some Jenkins compatibility because I need to do some other task probably Tecton can't do. They should be able to easily integrate into Tecton client plugin with the same configuration that they've already put. So that would be nice to have. If we are able to restart I think we can keep that as a minimal goal for the project and I'll try to sketch out a design doc which tries to cover this but I'll try to sketch a design doc for this one. I'll take that as an action item for next week. Awesome, thank you. Do we have any more questions or comments on this? No it sounds good. I've got a meeting on Monday which will decide exactly how much time I can dedicate to this so I'm kind of hanging back a little bit until after that meeting but that should give me some clarity. Okay that sounds good. I wanted to ask so how do we go about proposing an architecture in the Cloud events workstream workgroup in CD foundation on Monday. So Monday we have that we have the Cloud workstream meeting I think. So I just want to ask like we already have the design doc and everything so do we need anything apart from that to kind of discuss the Jenkins Cloud events support? I think bringing it forward to that to that sake is a great idea and they may be very interested in especially as it begins to be developed and put into production as a case study. I think that that could be really interesting. It would be good to have a few more eyes on the design doc. Kara can you suggest how can we get like more people to review the design doc should I post it somewhere some channels? The email channels where you have posted it is tends to get would be the most obvious place to post it and you may want to post it as well on Jenkins CI dev just because I think there are many more people on that email list so that might be a good place and if you are interested although this feels a little early to do it but it would be great to have a blog post on this at some point. I would really like to see that. Those are the most obvious ways I can think of getting more engagement from people. Do you have any other ideas Kara? Anything I'm overlooking? No I think that's good. That's a good start. Would the blog post be before the creation of the plugin or after? Certainly after. I think it would be great to announce it but if you want more engagement and feedback and kind of get momentum on it I would certainly be and you've proposed it as a GSOC idea. I think it's quite interesting to talk about both of the plugins that you're working on and maybe discuss what you're aiming for, how you're seeing this help evolve Jenkins use cases, improve in certain areas. I don't know I think there's a really good story around that and if you're interested in writing that blog post I think it would be very good. And I think if you've got like future road map ideas sort of thing like highlighting what those could be like the scope of the plugins in the future could look something like this but the GSOC proposal it might just be a small piece of it but explain how that fits into the big picture that's really useful. So big picture is basically interoperability one word but yeah it's it's just it's just part of all that but it'll be nice to see multiple things working together with Jenkins way more easily and in the most standardized way. Definitely and when the work when the plugins are you know completed and and moving forward very well this is a great story for the CDF and for the interoperability sake so there could be a lot of a lot of momentum and promotion then there and for now I would say definitely bringing these ideas to the sakes both the cloud events sake and the interoperability sake is a good place to get wider feedback and maybe interest I mean you never know people could really dive in like just depending on who who hears the message as it were. That sounds good. So um actually we have in our chat here this is a good question what is DSL and then is this DSL and we have a link to um Jenkins job DSL. So DSL stands for domain specific language and in my in my understanding of how this works a lot of the a lot of pipelines have their own domain specific language and Jenkins certainly does and so and am I correct and saying Tecton does as well and then what what's above this thinking is that a student would make sort of a specific DSL for integrating um Tecton tasks within Jenkins does that make sense is that correct above correct me. Yes that's basically it's just a fit so it's it's a so I'll still kind of I don't know how much I can elaborate but uh it is basically that you should be able to talk to uh find a way to talk to Tecton using the Jenkins groovy scripts so Jenkins through the Jenkins file so that uh developing that part of the Jenkins file through which uh we are able to communicate to Tecton that is the DSL does that answer your question okay any other questions good any other questions or topics for discussion good okay so above you I'm sorry I spoke over you oh no I just said okay so you I once again have the most action items I'll follow up with but I can see if you would like to present again on the Jenkins um Kubernetes operator and um help you've above in in any way I can in moving forward your GSOC proposals in the next week because they go in next Friday so pretty exciting by go in I mean they're submitted to GSOC application okay that sounds good so uh this means that uh okay I will try to get the proposals up to the mark as they should be and probably we will we should sing we will sing during the GSOC uh office meeting right uh office hours and are we discussing all proposals at that time by any chance before submission all the draft proposals that are on the website now and they will go forward as part of our application what we're doing now is just last minute refining more resources for students any any extra um issues for them to look at and mentors gathering mentors but essentially all of the Jenkins GSOC proposals as they're up now on that on the Jenkins website will be put forward as GSOC project proposal ideas does that answer your question okay yep thanks Bella yeah thank you very much thank you all yeah thank you very good have a good weekend everyone