 All right, welcome everyone I'm Liam Newman bitwise man on Gitter and Andrew Bayer who'd usually lead this meeting is currently out He's on an airplane. So no way he's gonna be joining us today So Get started We have some stuff from previous meetings I don't think we really have a quorum to go ahead and go back over some of those Andrew had a Task to follow up on I believe in terms of Talking more about the developer experience, but we will come back to that. It's been two months since this meeting. So we had a couple of other Events that overrode this and We just need to come back around Then the one item on the disc on the list for a day is talking about this feature across from Michael Michael do you want to talk about that? Yes, I like to talk about it and show something. Okay Um, should I just start and show my screen? Uh, yeah, I can I can set you up for that one sec okay So the topic is generally general about uh, microservices About building and deploying them Because mostly you have a one git repository With a couple of my Hold on just a second. Could you uh make this larger if it's gonna be what you're sharing? Okay One sec Uh Are you are you mean my screen? Yes, exactly. Ah, okay. Okay. So, okay, perfect so It's about a microservices Generally, you have a couple of them like this is a showcase from Microsoft Ezra It has four um microservices And mostly you want to build test and deploy them independently And I think there's room for improvement for the Jenkins pipeline syntax I've wrote um Jenkins file for that. Uh, this is showcase for azure DevOps And in azure DevOps, they have this One cool feature that you can say it only includes the path of the microservices like captain cube So that only if a change is detected in captain cube This microservice is built And I tried to write the Jenkins file that's That's mostly the same But it's not Nearly possible So I've I have this um Jenkins file with just a simple build pipeline and it And you have this um You can use a Venn block And in the Venn block you can say is triggered by a user because you always want to be able to build it manually and that do uh And if you have a change like for instance in the Microsoft it's an environment very very able Which is uh done with uh It's like the first part of a multi branch drop And The bad thing is I have to declare such a meter stage because I Cannot use the Venn block at the top level And yeah, okay And if you take a look at the Jenkins you see I've done a commit to dummy commit to to note Brady and if I do this the other pipeline like for captain cube is Still running and says, okay, you have a dummy commit and it's not inside the Venn block And you still have this This this build where nothing happened, right? And if you have a microservice, which is uh Really changing then you have a lot of builds where nothing is done and My feature request is that you can Define something like these uh Venn block at the top level And that only if the Venn block is matched that A build is executed and then uh So I imagine what you would do is you'd have multiple Jenkins files then right currently I only have one Jenkins file and I am Matching like the the the drop name So like the the the drop name of this multi branch pipeline is captain cube And it's get uh extracted at the beginning of the Of of the Jenkins file like uh In this line So if you had more than one microservice in this repository, what would What would that look like you have a different you'd have another meta stage um I currently the idea is that you have one Jenkins file that does the same for every microservice. Ah, okay So then when So I have this meta stage only for the Venn block Otherwise I had to specify this Venn block in every stage Got it. And if you make changes So the point of this is that if you make changes outside of One of the microservices that it doesn't Go through that it doesn't run the pipeline. Is that the the plan exactly? Okay okay And so the syntax that you're you're thinking of is to have like a Venn block at the top of the pipeline right Okay, and do you think this Is feasible with the current implementation of the Jenkins pipeline in general So that again, Andrew would need to be here for for to talk about that because I would know I don't know enough personally to to be able to talk about it. I can talk about the design overall, which seems like um this isn't A bad way to go. I think I think actually having having that wind clause could work um In a larger sense. So if you had for example multiple um either Instead of just having a Jenkins file if you had different named Jenkins files This would move and this would help with that. So you could you could guarantee that this particular pipeline only runs when It's associated microservice or it's associated part of the The pipeline part of the part of the repository is changed um This would be a fine tool for me. Right. I can see a bunch of cases where this would be uh useful to have as similar to um how we define uh build parameters and some of the things like that where it makes sense to Have the ability to to control this at the top level. Um, I think there's some And if we ended up for example making a change where we could have multiple pipelines in one file, then the the wind clause that top level pipeline when the pipeline wind clause would would uh, Make a lot of sense at that point. Um, so there's there's a bunch of places where this seems like it uh, this would be a useful feature to have I don't as I said, I don't know the details of um, how you would of whether or not the design the underlying implementation supports it well, but That's a secondary problem. I think that The Design the the feature request makes sense to me anyways Jeremy did you have any comment No, I was just paying attention and listening in on it because it did seem like something that my company would Be able to use because we do have some java projects that are using shared Uh one repo that has a bunch of microservice, uh, share that are shared amongst the uh, and they currently just Do it all in one build but to be able to split it up might be More advantageous and allow them to be more agile Yeah, we have we have the same that you have a couple of microservice and you have only one jengets file and you Build every every time you build every microservice, but that shouldn't be needed. I mean, yeah, that's exactly what you're doing The microservice if you have to build them all together right Okay, so I mean, I think that that in general this makes this, uh And I don't think I can't do any any place where andrew would disagree on this one. I think we're In agreement that this is a good idea So Yeah, so I don't know. Are we planning on implementing it or was was this more like a I know the end was and just got it on him on his plate. I see okay It was more like a proposal. Okay, everybody would like to see this kind of feature Okay, well then yeah, I mean, I think that's Certainly reasonable to have um, so and then just got it on his plate. So I I can't speak for him per se, but this Uh, this seems reasonable to me Yeah, um, I my understanding of of our of his amount of uh work his his workload might be that he doesn't have time in the next few weeks, but definitely this um This seems like a good feature of me. So Yeah um I mean and uh, so what would this look like to you? Do you think just move adding a when clause that exists in uh next to the The agent and options and other things like that Yes, okay. Yeah, that makes sense All right Well, I guess um, we can add some comments to the uh, To the it's about to just sort of show what the what that would look like Yeah, the only thing that I could see of with that potentially with that then is you're using your your environment variable to Set the microservice name to get it from the tokenized job name Uh, would the when statement still be able to access that? um By the order of operations which gets processed first on the when or the environment Right That was something that I was running into when moving my our our pipelines from scripted to declarative was Uh, finding some of the stuff that was not Processed by the time Right just a thought Yeah, so we just need to pay attention to the uh to the order of operations that the when would occur So it's an interesting point like do we does the when occur after the when would need to occur after the uh Parameters are processed after the environment environment variable is is covered. Um Yeah, so there would be there would be uh, you would still get like I guess Pipeline runs that would have to uh Because it has to run in order for you to do that Yeah, I mean you could implement something hacky like you do a post block and Check if the build has done anything and otherwise to lead the current build, but I think that's That's not really uh Yeah, this this is going to be the same Uh, this is going to come into the same sort of problem that we have when uh talking about When you change the parameters on the pipeline That you have to actually run the pipeline once to have those Changes to the parameters be picked up because the job isn't It's already started running When the that parameter block is evaluated So there's a there's something here where we need a bootstrap spot for these things anyways um that is Load up the pipeline Take a look at some things and then Actually run it or something like that, right? There's a Some that there's which indicates to me that there's definitely that this would be a bit harder to do just because of by design just because there's we don't have that concept of like Pre execution execution Yeah, which is essentially what this is is a pre is a pre not necessarily a post right so there's that that's that that's a good point and that said I mean like once that this if we If we implement this then the that might open up Fixes to other things including the parameter changes and some of these other things where order operations like hey, there needs to be a a pre Block that gets evaluated And and figured out or there's things that need to happen quote-unquote before the pipeline has uh Is actually Executing in some way. There's there's some some process where we need to a bootstrap step Yeah, because that declare I mean even to do to use the change set that declarative scm stage has to occur right yes so hmm Anyways, yeah, okay. So that's a good point that we need to that that's gonna make Highlights the fact there's gonna be some design implementation complexity here, but Yeah No wrong key. It's already assigned. Um So yeah I mean, I think that this is a useful feature the the question about whether or not it's implementable needs to be That needs to go through a process of like actually researching that and discovering whether or not it's gonna work Andrew might would probably like being bringing all brainy would know off the top of his head Um at this point, I'm just gonna say it this seems like a useful Feature and also in the process of implementing it. We would We we could actually unlock some other things that have been That are you know friction points. So cool Hey, Tyler should be in a fly on the wall That's sort of just listening in excellent Well, um, I unless anyone has other things to uh discuss I think that's actually what we had for for today I will take some notes on this and post them And uh, the next meeting should be the second wednesday in may Any other comments? All right Thank you all for joining and uh, I'll see you on, uh, Gitter or otherwise the next month All right. Thank you for your time. Thank you. Thank you