 Welcome. This is the GitLab plug-in modernization project meeting. It's the 16th of June 2023. Topics I've got on the agenda, action item report, schedules and events, pending pull requests, and discussion on reviews and any results from those reviews, and a review of the mentor checklist. Anything else harsh that you want to be sure we put on the list? Like the discussion of the project plan, like the discussion of the second milestone plan that I have. Oh, good. Yes. All right. So let's put that very high on the discussion of plan for the second milestone. Good. Okay. We don't really need that now because upstream support has come and we have a GitLab 4J 5.3.2 version, which has all the changes that we want, so we won't need that anymore. Wasted effort. Oh, good. Okay. So library is library. So let's say library is an OPS library is now available upstream. Yep. And you said that was 5.3.2. 5.3.0. 5.3.0. Okay, great. We won't be using the 6.0.0 now. Okay. The only difference was like the 5.3.0 version has the least minimum support for Java 8 and the 6.0 versions have now the minimum support for Java 11. So I don't think so we'll be using 6.0 right now like I could have been the initial tester for that but yeah. Okay, good. Well, now but doesn't 6.0 also require GitLab 15 or newer it's got some. Yeah, yeah, yeah. I forgot about that. Yeah, that's good. Whereas 5.3.0 is GitLab and I don't know what the older version is but it's something older than 15. I think it's 12. Well, I think like I don't really like I'm not sure about it. Right, but and five just from my education five is the one we're already using this is just a newer version of five. Okay, good. Yeah. Good. All right, just got released, like I think the maintainer twice and he released it so yeah, I just messed up his head for some reason but yeah. Excellent. Very good. Okay. So I think we've got good items for the agenda. So we spend a minute on the action items before we get into the other thing so you had a note on creating a U.M. UML diagram and I see in the Gitter chat that you've posted an image that looks actually I'm just going to drag it into the document because I don't think it'll hurt us to have a copy of it. Whoops. Okay, let's put it here. Can I add it in project plan if you want. Also that would be good I just want to capture it here so that we've whoops capture it here to be sure we've got it. So, of apparently I am unable to do drag and drop property just a moment let's try this like copy pasted right. Yeah, apparently I need to learn how to do. I'm going to outline things like that. There we go. Okay. So what this says is draft diagram is available. Like is better joining or Chris. I don't see anyone else. Why I don't, I don't see them all ping Basel and see if he's available. Let me ask Chris as well. Let's check. So like I'll have to discuss this. Before the PR is actually made like I haven't really started working on the pull request yet, because I, I got busy with the previous academic thing and like I was planning to make it much faster but I just got slowed down by some random nonsense that I had to figure out but yeah. Understandably and that was the right choice right that was absolutely the right choice. Chris. And Basel. We've started the session today's session at and let me get the zoom link. Where is the zoom link. Okay, there we go. And great. Okay. So, do you feel like this one we should just call it done because it looks like a good diagram to me and you'll keep evolving it. Yeah, I'll be keeping, I'll keep evolving it as I discussed the Basel and Chris, but yeah you can just because I don't need to work on a lot more on this, this diagram of course that it will require some some changes if it may have. So yeah, you can take it up. All right, excellent. And then I think let's put one more action item here which is and this is a new one. Mark test latest development branch interactively to match with because you've tested it interactively and Chris has tested it and harsh. Good. Okay. Go ahead. Yeah, I go ahead. Like should I go ahead. Yes, please. Yeah, so the Docker base test, like some of them are feeling and I knew that those those were going to happen because Basel said, said that they should not be working that easily. No, I'm quite leaving leaving it for now. Like, if I complete the second milestone, no, not a second milestone. It's, it is a stretch goal right. So if after completing the whole project, if I get the time then I'll try doing it again, like it's not that big deal. But the problem is that I'll have to set up the get lab instance and just start the debugger it's a very slow process for me to test all those tests. So I'm just lacking off for this. But yeah, like also the midterm, because I'll be having the recorded session in the live live session of the midterm presentation that I'll be that then because of that I'll be requiring to complete the second milestone beforehand like I think till the end of June I have to complete it because like some testing will be required for that recorded session to work as said by Jen mark that you have to test if it's going correctly or not. So that's why for that reason also I want to take things a bit faster on the main goal project side as compared to stretch well and and that's I think that's important right so second milestone needs to be complete. Before your exam start right before the beginning of his exams so that you're we're not just disrupting your examinations and that second milestone includes some form of presentation. Of the results when the way to say is this, am I talking about the right thing here. Yeah, okay. When the second milestone is completed will have to do a midterm presentation related to it because it will be the major chunk of the project like it was completed then almost the project isn't a very good practice. And, and the idea there is, we'll probably have to do that as a recording because rather than live because lot the date of the live session is during the middle of your examinations right. Yep. Okay, good. I discussed that with with john mark and Alyssa and Bruno and Chris. Yesterday, and they're aware of it, and they're trying it looks like there may as be as many as two of the four contributors who will have to do it recorded. Yeah, like, one bit and me. Let's talk. Well, hey, your university. That's that's appropriate you're, you're supposed to be at the university that's good. No, no, actually not we are suffering from an asynchronous semester due to COVID-19 that's why it is happening otherwise, things have been so so smooth. Oh, okay, so, so the complication here is not a standard complication it's, it's truly exceptional duty COVID-19. Yeah, that's why that's why I'm so slow with all these things that I'm doing. Okay. To pre record their presentations. Good. All right. Okay, so what else you said we want to be sure we discussed the plans for the second milestone what other points need to be on the second milestone. Or what are there other things that I need to be aware of. So this is what the second milestone is about. Okay, we'll be migrating the webhook implementation to it's not like the webhook and I'm you I'm using the github for this webhook implementation just to abstract away some lower level details. It is not that as major as you think it would be like the project plan, the project of migrating from rest easy to get left for is actually done, because we are not using rest easy anyhow like it is not being used in the first PR that I made, I actually migrated everything related to rest easy for to get left for J. Now I'm trying to use the extra features that are provided by get left for J for handling the webhooks also. So that we can abstract away from the lower level details and make the plugin more concise and modular like the main goal of the second milestone is to make the plugin more modular. Like, I'll be discussing it more than the, like, the UML diagram that I shared like I'll be explaining it more briefly. Great, well so do you want do you want to take the time now to do the explanation or would you rather know anything anything else left. The things that were on my list upcoming schedules and events we know about the, the, we know about the midterm presentation. And the midterm evaluation. And I'm not aware are you are there any pending pull requests that need more reviewer discussion. Yeah, the first milestone like I don't think so best I have reviewed it left yet. Like, I also enable the tests and if that's what the Docker base test for failing others were passing. So, like, good. Okay, and tests tests are now passing there. Right. So, like the Docker base tests are not passing. Right, right. But the Docker base tests have been failing for years. If I remember our last, our last comment right. They and they're completely outdated. They're based on an ancient get lab version right which which no one cares about anymore. Okay, good. And so we where we accept accept the long, long dead container based tests. And my assumption with those container based tests is it may be a full re implementation, because we have to get new container images right we need something based on get lab 15 or get lab 16, not not. I think it was get lab eight that the original service. Yeah, like it's very old like it's right, right. And that's testing against something that old is just not relevant. Right, it doesn't matter to the users. If they're using that old a version of get lab then they'll probably never upgrade to a new version of the plugin. Yeah, they need some help. Exactly. Okay, and the other let's see review items. This is where Basel and I both need to do reviews and the mentor checklist. I believe we already talked through that last week and saw everything on our list. We've got the midterm evaluation we've discussed. And online presentations good. Okay. So I think we've completed the items for the meeting you want to spend some time looking at the talking about the diagram. I will be spending some time others didn't know nobody has joined. So yeah, okay, that's fine. They can they can refer to the recording for this like I'll explain it in detail now for that. And regarding the regarding the pull request, like the first milestone pull request, Chris has Chris has actually made a checklist for thinking what is wrong and what is right, so you can also refer that like. Oh good. Thank you. Thanks very much. Excellent. Can you just make it bigger. Absolutely. People will be able to see it comfortably. How's that let's let's go full screen and move around. Is that now I've got a scroll. I think I should share the screen maybe I'll show you some code also that. That's even better let's do that I'll stop sharing. And then you can you can share so just a moment stop share. Go ahead. Wait a minute. Is it visible. It is visible. Yes. Yeah, it's real right. It works. Looks great I can see the text everything. Okay, so let's go to some. Okay, let me explain what's going to happen like this is just a draft that I am going to explain to you guys, but yeah. So, once the get lab sends a web hook request, they get the request to through the get done like we use the request and the response over here. It gets the project name stapler request of Jenkins and stapler response and we use this through the get dynamic method that's here. This get dynamic method uses it logs it. And let me remove the fact that it's not like what I'll be doing is, I'll be setting up the web hook manager here like I would I've commented on the code but yeah that's what I will be doing. I'll be using the web hook manager here to add the event for this request and add the listener I'm not implemented the listener yet, but I'm going to, but it's going to add the listener here, and the action like uncomment this, why am I going to do this. The action resolver is going to resolve it, and also execute the response like I'm going to explain what's happening what's going to happen. Now, so, so this is a get request and, and protocol level it really is a get request. It's also, it's a get as a post request. If there aren't get requests I thought that get requests were not allowed to be state modifying. Isn't there a risk that this will cause state change. Should it should it be I guess what I'm asking you should it purely be a post. No it should not purely be a post. It should not the order. Yeah, the originally the code had the guest and get the guest request and the post post request both implemented manually. So I don't think so get request is causing any trouble because it was already there beforehand. I'm not messing around with it. Okay, so it, the plugin already has a get request here. And if, if that get request that's that you're implementing does the same thing as it did before. It certainly is no worse than it was before. Wait a minute like I am not going to change the get request thing at all. I don't know about it. Okay, that get left for it does not provide us anything. Get left for there has nothing to do with the get request that we are using it just for telling Jenkins something has happened and telling get left something has happened. But it has nothing to do with get left for get left for the only handles the post request. And that's what I am going to be. And that's what I am going to change this thing which I have written. It's just describing existing behavior. In fact, he wants to have a look just by the diagram what's going to happen a second milestone. So I just for the sake of completeness that I, that's what you can say, I did that the major part is going to be the post request that's why it's discontinued from here like there is nothing here. Okay. Okay, it's mine. Yes. Yeah, the action resolver. This get lab webhook. So the webhook manager will be implemented here. And now we'll get into the action resolver. Now this is the action resolver, and we'll create in will create an object above this. Now this has the get request already set up the get request here. Now I'll show you the changes that I did. And a lot of it's all it also had a post request, which to get request, but I'm removing, but I'm removing the post request, because the get left for you provides us the option of directly listening to the get left through the get lab API itself, without manually implementing the post request. So I am removing that to make the plug in more concise to code. The get request the get left for you have get lab API itself doesn't really have nothing to do with the get request. So I'm not missing around it. Okay, so even changing anything. So in this case what you what you just said is that the post request that previously was implemented inside the stapler stapler framework is no longer required there because get lab for J API provides it for us already. Yeah, it automatically triggers what is like, I'll be explaining it more detailed. Let's get started. What's going to happen more like on the on post like this method was used to get there is like we were getting the response that the request and through the request header, we were trying to check what was the thing in the request about like was it about push hook or tag push hook or whatever. And after that, we were deciding on the action. Now, again, using the system hook also like a bebo kind of system hope both were implemented. So system hook was also doing the same thing. So this is the code which I'll be removing because I don't think it was useful at all now, and a concise version of it will be used now. So what I'm trying to say is there is the diagram. Yeah. So this action resolver that I that I showed you just now it had the webhook listener webhook manager system hook listener system hook manager implemented like that's how it will be. You just saw the posting I'm replacing the posting with the GitLab 4j thing. Okay, fine. Yes. Okay. So the post request will be managed on the events for respective events on webhook and system hook. The webhook will have will implement all these events. And I'll show you how I'm trying to do it and system hook will do this. Okay, so action resolver. I haven't comment. I cannot life code. Okay, let me explain. I didn't really, I think I coded it but I removed it for some reason. I can't really remember now. So let me explain what I'm trying to say here. So what we're trying to say here is, Oh, no, I have better options. That is my lovely project manager. Yeah, that's what I'm talking about. Like these things like on push event. So this method calls the webhook push that has even that has been received. So what I'm trying to do is I'll be implementing the webhook listener by overriding the methods that are by overriding the methods that are implemented in the GitLab 4j to do what I want to do them when GitLab actually actually sends the webhook request. So when GitLab will send the webhook request, it will automatically trigger the on push event like suppose the GitLab sends a push request, push posted request, then it will automatically trigger the on push event. And everything that is residing in the on push event will start happening now, instead of waiting for the post request like what we had to do previously was to check if it's what it was a post request and find out if it's a push event or not and then do the action. Now GitLab 4j has concise state and we can simply check it. We can simply know if it's a push event or not. And now we can move ahead without taking care of the low level details. So are you with me. I am yes so so really all of that logic that you showed as deleted is being deleted because it's implemented already in GitLab 4j. And have you confirmed have you confirmed that this works as you expect with at least one of those. One of those events so that GitLab 4j's API is really able to listen in when running inside a Jenkins controller like this. Like, that's a good question. So I haven't really checked through my coding like I didn't really code it because I didn't have much time, but what I did was I tried finding all the repositories on the, like on the GitHub, which used to get to GitLab 4j because GitLab 4j is being used in other repositories also. So they are also going to implement the same thing that I want to do, right. Right. I checked them to find if they are doing exactly what I think they should be doing and I think like I'm, I'm right. I also checked the brand, I also checked the brand source plugin for that. And brand source plugin also uses the same thing the same logic that I'm trying to use in a slightly different way, but yeah it's doing the same thing. So the GitHub branch source is already using GitLab 4j's web. Sorry, I said the wrong thing. The GitLab branch source is already using this web hook concept and on on XXX event to do its work. So we already know there's at least one plugin that's successfully using it inside Jenkins. That's great. Okay. So I actually refer to two, three, two, three different projects for that to make sure that I am on the right track. So that's what I thought. Like I'll try coding it but I didn't really have that much time. So I had to take some shortcuts to get there. So related to system hook and web hook. So what was I saying? Yeah, both of them have similar kind of events. And that's why both of them are dependent on the same kind of actions also, like the push build action, merge request build action, all these actions are based on both of them. So I'll explain you a bit about that. Where is the action. Like, wait, I have to explain something more before I try doing that. Right. Yeah, yeah. So, yeah, I'll be showing you the difference between the web hook and the system of things like why are the different in their implementation in their manual implementation I must say. So, simply in the way to me, simply on the on post, we're saying that it's calling simply the merge build action with request body of the request in the token header. Fine, but on the system, the book thing, it's trying to make a JSON tree out of it, like it's using the utility of JSON utility and trying to make a JSON tree like it has used a JSON node for it, and then it is calling the same classes. But with the JSON tree instead of the JSON itself. Do you understand what I'm saying. I think so so it's, it's constructing a tree of JSON objects and passing the JSON objects instead of expanding them into the actual jank JSON literal text. So they are using some different things there. And regarding to get request body we don't read it. We don't need it, because the request, the request body was required so that we could read the tree, but now as get lucky has provided a convenient to do it without getting into all this ruckus using simply using the events that it has because the web book manager actually extracts the payload and does everything that every logic that it is implemented here. So, it is not really required. Going to the actions. Okay. Yeah, so you can see here. I was trying to read the action like it's getting the JSON node. This is what this is for the alternative this is alternative constructor for the system hook. And this is for the web hook. It's it's get simply, it's simply JSON. And it's the JSON node. So they are the different implementation, but the same push build action object is being created that that will be tested for the compatibility with the previous and will be executed simply on the based on what's what that call. Yeah, it will simply be executed when the webhook action is being called. And other than this, the SM not notified does not require that this won't require any change. It's what it is trying to do is it gets a trigger notify object and not push even not prevent on post. What was pushing. Yeah, like this. This is what it's going to do it's going to trigger on post event, which is here like I'm taking example just to push but it's similar for all like all four of them. Right. So it's going to go to the on post which is here in the good lap push trigger now on post will receive the push event so I think I should be explaining one more thing. Yeah, the webhook thing and the webhook and the system hook, both are using the same build actions and the build actions will send their respective events like the push event to the on post method, which will handle the things afterwards. Like one more thing that I should be explaining to you guys is why am I where is it. Yeah. Why am I implementing the webhook webhook listener and the system hook listener in the action resolver itself instead of the good lap push trigger. I have a reasons for that. I could have implemented in the good lap push trigger but because it actually looks better in the good lap push trigger to do that but I'm still doing it in the action resolver, because I want to call the build actions which I'll be not able to do. If I try doing it in the good lap push trigger because build actions call the push trigger not vice versa. So what so to retain the flow of the program. What it was before so as to create less noise while the development, what I'm trying to do is I'm trying to retain the complete flow of the program. Just by adding the tidbits of get lucky in between to reduce the content of the code and make it more concise, but still following the same pattern that it was following beforehand. That's what I was trying to do. Okay, that sounds very reasonable to me so it's an intentional series of small steps that you're taking each one still should work and should be in atomic in the sense that it's it works by itself within the existing code base I like that very much. Yeah, so the whole idea of the migration is the user should not feel anything has migrated at all. That's my idea. They should not know what has happened. This magic happened. That's, that's what I'm trying to do. Great. So, so the on post slide. Yeah, it will receive the on post and it will distribute it to the individual handler. Now, like these things these actions I didn't really explain because like I am not changing anything. So yeah, that's just for completeness. So it goes to the handler. Where is my. Yeah. So as you can see, it initializes the initializes the handler. And yeah, one more, one more thing. The filters. Yeah, how can I forget them filters. I am not going to change filters much because when I when I was researching about the filtering options provided by the GITLA for Jane, I actually found that it is providing the branch filter but it's not providing the name filter and the regular space filter, which is kind of a bummer like it is not giving me the complete thing, like I was not able to find more about it. So I think I should be using the filter. And another reason is, like, in the read me files, the user can set the branch filter type or the name filter type manually, programmatically. So I don't want to affect that also. That's why I'm not going to change this also. Even if you provide it somewhat but I'm still not going to change it. I'm going to use the filter that are provided by provided by the plugin, the old plugin itself. So you can check that out. You can check that also if it's the correct approach, or you want to do something else like I'm going to advise. That makes sense to me you're choosing to to retain as much of the retain the existing functionality right not risk disturbing the existing filter functionality makes that makes good sense. Okay, so like the next will be the handler will be called, but it will take the event instead of the hooks and that that is also an important thing which I'll be explaining now. Like pending builds handler and webhook trigger handler webhook trigger handler. This what what it was doing was my change what it was doing was it was extending the webhook. Instead of extending the webhook it will now extend the event because we are not extracting things manually through the hooks instead we are relying on get lucky to provide us the relevant events with the information that has been extracted from the webhook manager. So I think it will not extend the webhook now, and it will instant extend the event now. Is that a risk to are there people who are dependent on that old interface are their consumers dependent on the on the, the previous the current definition that will be broken by a change to, to that that definition is webhook trigger handler used outside of the plug in for instance. Outside the plug input like it's a nice question like I haven't really thought about it. But yeah, I don't think it should, but I have to think. So, so jump back to the place where you were talking about switching from extending one thing to extending another. Yeah, yeah. Okay, so instead of, instead of extending a webhook, you're, it's now going to extend an event. And so that that is a compatibility change right that's a, that's a change and it could be breaking if someone depends on this API. I, so it's, it's probably it is worth it for you to do an investigation to see if there, there is anyone outside this plugin that is dependent on the public interface webhook trigger handler. Yeah, I think I should be thinking about this more a bit more, because like, we were using the webhook previously, like what I think we were trying to do is we were using the previous webhook like it was a manual webhook. Let me show you what it is. It's simply this, like it is a manual infrastructure of the webhook that we're trying to use, but we have to extract information out of the webhook you saw that Jason thing, we don't need it anymore, because get lucky already provides us. We don't need to convert it into Jason and using the Jackson, Jackson conflict thing, like what was that name, I forgot about it. Jason Jackson, I think we don't need that anymore. We already have the information provided by get lucky to us easily. Yeah, go ahead. And when I look at I just did a search on with GitHub search engine, and the webhook trigger handler as far as I can tell is only used in the GitLab plugin itself. Then there is a what looks like copied code using the same thing in the in another plugin, but that other plugin has has the code in an entirely different location. So it's perfectly okay because here the webhook trigger handler is inside a J get specific package right or not a J get any inside of a GitLab specific package. Yes, there it is, or GitLab for J. No, scroll, could you scroll up to the top so I can see the package name. Yes. Okay, so it is this is very much inside a GitLab plugin specific package. Okay, thank you. So we'll be extending the event like that's what I know like, of course, if any problem, the spring on the GitHub channel. Right, of course, related to the abstract webhook trigger handler. Now we'll be using the events. So as we are using the events, these all things will be changed course. Yeah, yeah, related to the handler, how it will use the web events instead of the hooks, and they cause data my lovely little cause it up to this cause data. This humongous thing needs to be changed because it's what what it's trying to do is it's trying to collect the cause data for all possible events in a single file, which is not maintainable like I don't think so it's a good practice to do it, because it creates a lot of mess like you have to get in get things null and get things normal. It is not good like we have extra things, which we don't even want for that event. So what I'm trying to do is I'm trying to break it into different cause data classes, and I'll be using GitLab webhook class for like setting up the thing to work fine like orchestrating the thing correctly. That's what my approach for the cause data changes will be and the handler that we have these handlers will populate the respective cause data using the events that I have, like I'll be using the push event that is provided by GitLab project to me to extract the information of the payload and populate the cause data the respective cause data, instead of using the hook. That's what I'll be doing with the handler and after that I think everything will be sorted like the I just intercepted GitLab 4j in between the things to make the plugin more concise and the pattern is still the same so I think the plugin should work end to end after this changes. Fine. Yes, fine. Thank you very much. So, did you understand what I was trying to say. I think I do well and we've got the recording so I can refer back to it if I have further questions. Okay. Nice. Okay how to close the screen share. There's here I'll just I'll click the stop sharing. Yeah, I found that. Oh you did good. All right. Harsh, any other topics we need to discuss. About closing the draft PR. So like I made the draft like to draft the first reference in draft PR, I think I'll be closing them after the review is done for the first milestone. And related to draft PR that I made to the GitLab API plugin, like the maintainer of the GitLab project plugin also mentioned me over there that like it was some changes and we decided that 5.3.2 version will be used instead of the 6.0. So that draft PR also be closing. Right. Nothing else like I think I've covered almost everything that I did this week like I did a lot less things than required but yeah whatever. Well, thank you. Thank you very much for your progress and we'll we'll talk again in a week. I've got reviews to do Basel's got reviews to do. There's a lot of interactive testing to do so looking forward to making further progress in the coming week. All right, thank you. Thanks very much. Bye.