 Welcome. It's 19th May 2023. This is the GitLab plug plug in modernization weekly Google summer of code status check. It's community bonding period. Let's see harsh. We've got that checkbox item from so from our past action items. I've still got to revise the project page, and I did create the community page and upload the recordings I believe so I think that part we've got. All right, so harsh I think we're ready to talk about project plan review. And yeah one more thing the blog post is also completed so. Oh it is very good okay so blog post is complete. Very good thanks. Alright. Let's start the review the project plan. Okay, so here are the notes and I'm going to make it bigger. How do I do the view thing. I'll just do it this way. There we go. Okay harsh how would you like to take us through the discussion. So related to the dependencies the like, we'll add the GitLab for the dependency so I wanted to ask, how will I check the compatibility issues like I, from the main one repositories I added the link for the dependencies like what dependencies is GitLab for the using. So how am I how am I going to test the compatibility thing. That's one of the issues that I had. So when, when you add this, when you add this, and if you retain this so during the transition period I would think you would want both of them included. And, and then you'll change API by API. Yeah, yeah, so in terms of that's the thing. Well, so, so Basel and I were discussing and one of his recommendations was for compatibility one of the best things you can do is use your debugger to actually watch the product execute watch the plug in execute using the old code so that you become familiar with it. And exactly what's happening inside that old code. And then as you implement one one replacement of something you can watch the execution of that same thing from a debugger, and see okay does it behave the way I expected is it getting the expected return values is it doing the risk sending the expected data and getting it back. So your question or did you have something I already thought of doing that and I will be asking more questions related to the debugger thing I have specific problems using the debugger when I was trying to debug the webhook thing and the proxy settings thing. So it's it's down there, but now let's don't talk about the debugger right now it's down. So, regarding the compatibility issue okay so I'll see through it like the idea that you told that having both at the time of migration. That's what I also thought but once I'll remove the rest easy then the problem will start happening that get LaForge will be having compatibility may have compatibility issues. So that's what I was talking about but yeah I think this answers my question. Okay. Ready to go further down the page. So the rest easy used to use client based things and the get LaForge is using API. So a lot of things has to be removed. I want to discuss on almost every class that has to be removed like we don't need to build a client right now. You can directly use the get lab API for that and as the version three is depreciated will be using version for and get LaForge already uses version for as its default API. So, other than that, the auto detecting get left client builder. That thing. I don't think so it is required and I would actually that's why it's not required. It's not required right. I had a question on that, like, even if it if I'm getting it right. And get lab API proxy will also be not required but I want to discuss on the proxy thing more. So I'll be discussing in the connection and proxy setting section. So am I getting this thing right. I think you are and so, in addition to so the existing code has a bunch of model classes to represent the various objects that are required because because get LaForge already already provides that so I will be removing the removing them I think right except I'll check I'll check if something has to be done with that if some extra models are used but I think almost all replacements are available in get LaForge. That's right so all the model objects can be removed as well as the client builder and related code and the and the proxy code. And that's so that's all encapsulated in the get lab for J library it's going to be a nice code removal in the end of this. It's really a code cleanup more than a migration. So yeah, yeah, it's definitely code clean. So, in the connection proxy set up, there comes the real meat. So API token implementation I don't think so harsh before we go on from there. I need to pause for a question on this one and probably to put about you and Basel. So, I've been terrified in the get plug in of deleting any class for fear of somebody else depending on me. In this case with this one it's, it sounds like it's a reasonably safe choice is that because we think nobody else should have been using these classes as a published API. But as a safe assumption. I mean, if anyone is is using these classes and a pipeline job, for example, it would be extremely unusual. Now I think there is probably at least one person out there who is doing it, because I did once get a pull request to expand the model to add additional things to it and I thought that was very strange because we're not. We weren't using that part of the API in our own code. So why would someone want to expand the model to include it. So I think there's at least one person who is doing this, but it's it's something that's clearly unsupported. Okay, so, so that's a case where if they were doing something particularly devious of looking inside the implementation and you and then calling it. Sorry, we don't promise to preserve that caliber of API compatibility. Yeah, I mean, it's not reasonable for someone to rely on an implementation detail like that. And if they, if they do need some functionality like that they could make the same migration that we're making by using the get lab for J plugin or the get lab for J library. Now one of one of my worries in the get plugin is that there are actual plugins that depend on the plugin. I just checked and for the get lab plugin there's only one dependent plugin and it's optional. It's an optional dependency therefore they I think that means we're, it's further indication we should be safe. Thanks harsh. So, yeah, connection proxy settings so get lab API token implementation won't require any change because it is getting it from Jenkins credential manager which I don't think so it requires any change. Now get lab connection so instead of getting the client we are going to get the API and the proxy settings which are which were implemented in the rest easy get lab client builder. I think we will be implementing it in the get lab connection. And can you can scroll down a bit Mark. Yep, so here are some questions like we have to discuss about the alternative constructors which were available in the get lab connection like, you know, let me check what they were actually get lab connection right. There were three constructors as I remember. Yeah, I got them one was using auto editing get lab client builder which I don't think so will be required now. Second was client builder ID extra which was using client builder ID and third one was using client builder itself. So we don't have those client builders and client builders ID right because of the get lab API so are we going to remove those constructors also. That's one question. Is there anything that's not being called and I thought if it could create some problem, if I remove those constructors maybe programmatically issues may happen. That's why I was asking because right from a compatibility point of view nothing should be calling them from another place in the Jenkins project. Normally we do care a lot about compatibility issues like this in Jenkins. So it's good that you're thinking about it. In the case of this get lab plug in the real there really isn't any other consumer of this of this get lab plug and you might know that if you're thinking about compatibility issues like this. The only place where it does matter is in code that could be called by user. So for example, if there are things like pipeline steps that have data bound constructors. Those are things that could be called by user who's writing a pipeline job. So compatibility matters in that case, but in terms of some internal class that isn't exposed to a user it doesn't matter. That clears a lot of things for me. Yeah, so the next question with that I wanted to ask was, how do I debug the proxy thing which is currently implemented using the http client engine because I can't really do that. Not able to do it, and it will be required because I need to. Really, what, what can I say, imitate the same thing that has been that has been done using the rest easy when using it for j proxy client configuration thing. So I've had some success in the past with very like going on Docker hub and looking for, you know, Docker images of proxy servers. I found a couple of good ones. I don't remember now what what their names were but there's like one that I found that allow you to just define the password and just run one Docker command to start up the proxy server with authentication. And, you know, even though I wouldn't use that image and production without looking at it more closely it was certainly good enough for testing purposes and save me a lot of time from having to learn how to set up a proxy server from scratch on my computer. Yeah, so I wrote some of them in my project proposal so maybe you can see that also I explained the proxy thing, much more in detail in my project proposal so maybe we can see that also. So, like, yeah, would you like me to open your project proposal. Yeah, that's what I was on. And now I need to find the link to that. Yeah, I think the link was there in the meeting. So here's the oh here it is project proposal got it. Okay. Oh, wait a sec. So, I'll just ask you to grant me access. I was not expecting this. The permission request from me to you should arrive in your email I think. Yeah, I'm opening my email. I was not expecting this. This is bad. Maybe I just clicked the wrong link now I don't see another so. I don't have permission either. Yeah, or harsh we could have you share your screen it doesn't have to be me sharing my screen you could share your screen if you want to show my screen I don't know how to do that. That's okay to then you're welcome to you're certainly welcome to just grant me permission to look at it. Yeah, I'll just remove it from restricted to anyone with the link that would be better and I'll be sharing on the GitHub channel. Why invest is great. Okay, here we go. Okay, I'm sharing it on the data channel get up like you get a channel. Okay. And so there was something about proxy here that you wanted to find. Like in the challenges section in the challenges section okay so challenges here we go. Yeah, authenticated and authenticated proxy so maybe we can read through this and maybe vessel can tell us if it's right, because that's what I thought and that's what I'm thinking right now I think this is correct, according to me at least. So, like, can you scroll a bit more down because I had those, I think it was called victim proxy or something like that which I wrote. Yeah, yeah that's a bit of a bit of more more. So, to test these corner cases like yeah, I was planning to use the proxy plan content class, and to text this corner cases, like yeah meet and proxy engine x proxy and proxy like proxy are these one of the things which you were saying or you have something else as a darker image I don't remember the name of the ones that I used in the past, but they sound these these sound reasonable at face value. But the proxy settings come from Jenkins itself, you don't need to, you don't need to detect whether. And, well I mean, there's basically, there's basically a page in the Jenkins UI, which is. It's, it's in like, it's in it's actually confusingly enough it's the plug in advanced settings page. I think we can set up the HTTP proxy and HTTP pro HTTPS HTTPS proxy through that. Yeah, Mark, Mark knows where it is. It's that advanced settings page here. And this is where this is where a Jenkins user can go in and configure the proxy by putting something into that server value. And then if they. So, you know, if they if that setting is, is not null or empty then a proxy is being used and then if they, if they have something specified in the username and password that that would indicate that you need to authenticate. So those are the things that you should basically be checking these values. And if they're not, then you would pass them through to the HTTP client. So I'll be using this thing for my debugging, then I'll be having much more clarity with the proxy thing, because I need to debug this thing first for doing anything. Yeah, so basically what you do is once you start that Docker image, you'd put inside of the server box, you know local host, and you'd put inside the port box whatever port Docker has given you. And then for username and password that would depend on, you know what you set it to when you start up the Docker image. Do you see. Yep. Okay, so this, this is the, this is the primary proxy configuration page, also for the get the get lab plugin. There's not a separate proxy configuration for the get lab plugin as far as I understand it Basel is that correct. No, this is the, this is the primary proxy configuration page for Jenkins for all of Jenkins. It doesn't, it doesn't really make a whole lot of sense that it's in the plugin manager because it really applies to everything that that everything within Jenkins. So it could be more properly be placed on the global configuration page. Right. Okay, so this is this is the one that's been been in the way of the get plugin, for instance on occasion gets is affected by this because this is really system wide. Okay, great. Thank you. That answers my question pretty well. So, like, I have a lot more questions. Can you open the project plan. I don't think so. I think here we go. So yeah, whatever. Regarding the trust manager like in the plugin I saw that the trust manager was disabled. Like so, are we going to use some self assigned or because the, it was written in the project project idea that TLS certification will be required so how am I going to set up the trust manager to get that plugin is using some extra build. I don't know, I don't really remember the name, but it is overriding all those methods and it was not returning anything technically the manager is disabled. So we are using the trust manager right. Yeah, for, for, for configuring HTTP clients. We usually want to just use the default behavior, but some sometimes our users, sometimes our users complain about the fact that like, you know, sometimes our users have target machines that don't have proper TLS certificates. So they usually want some kind of checkbox to be able to disable TLS verification. So we consider it a good practice to do that. But if you don't have a way to turn it off, then people with invalid configurations are going to complain that they can't use their non conforming configuration. But if the, if there's not, if it's not, if TLS is not I haven't looked at the current code but ideally, there would be enabled by default with some kind of checkbox to turn off TLS verification and if that isn't already the case, then we could preserve the status quo or try to improve it if we have time. Yeah, I think I get it now. Okay, that's good. Yep, so this section is over. Let's move to model the name section. So the most fundamental thing here will be that we are not parsing any JSON now, Jackson JSON is already available in the GitLab 4j. We will be using events instead of hooks, and we will be getting data out of it and filling up the cause data using that. So almost all the models and hook models will also be removed and we recently got a bug regarding the hook models also as Chris told in the Gitter section, Gitter channel. So yeah, that thing will also be solved using this models in Enum. So I think it's just like any problems. I guess. So it is good. Those support classes of publisher classes and all I wrote the code for everything like so that you could check if things are working properly or not some utility classes that were also there. So I think one of the utility classes was commit status publisher I don't think so it will be required because. No, that was a publisher class. The classes name was let me check what was the class name. The utility class. So is it project ID. No update commit status. I think I didn't write it in the project plan for some reason. So I don't think so big commit status will be required because we can change the commit status using get lab for j also so I think that will also be removed. And related to this, I wrote the code for my just migrating the rest of the client to using the killer for the API that's nothing after a month. So we can scroll down more. Until unless the coding part is removed. Yeah, so cause it I don't think so anything will be changed in the cause data, we can break the cause data for different events but I don't think so it will be required. Much as I saw that in the grid lab branch source plugin, as I remember, but I don't think so it will be required. We will be using events instead of hooks and that's the main crux of the web hook thing that will be that we will be implementing and related to the web hook thing. A lot of things has to be changed because we are not using hooks now. Web hook listener will be implemented. And the trigger will be fired to it the handlers will be the handlers will be preserved because I don't think so that it requires any change related to the trigger contact chain. It is using the hook models which were used by rest easy now will be now we will be using the models which are available for get left available by get left for j so that's the whole cross crux of thing. The issue that I'm facing in web hook thing is that whenever I try to debug it, I am getting into Jenkins core classes, which I don't want to get into. So do you have any suggestions or tips for debugging the web hook thing. That's a problem for me. I don't really understand the question I mean, are you saying that when you use the debugger, you're missing stack frames and you're going to deep or something. Yeah, I'm going to deep which I don't want to. That's a good problem I'm always getting into ACL classes or crumb classes that I don't want to and I'm doing step over I'm not doing step in. So, maybe I'm doing something wrong. Yeah, I'm not really too sure what you're asking unfortunately. So, so harsh. Go ahead. Sorry. I'll ask it on the data channel then it will be much clearer. I think it's not getting because I cannot really show you how the debugging is going on so it will be a much longer process so I think I'll ask on the data channel. In in next week session or in a future session we could actually do a shared session and have you share your screen and and actually talk through a debugging session so so there's no no shame in us looking together at what you're experiencing and seeing oh can we help understand what you're seeing and see is that what we expected you to see or was there some surprise and what you're seeing. Okay, yeah that that would be great. I think this is the complete migration and the birds I view and high level view that I have shared related to the timeline. I want to finish it faster of course, and I broke it into small PR that I will be making. So, this, I don't think so I need to discuss about this so any questions that you guys have or any suggestions. So you said you've already written some of this code and you plan to clean it up and submit it gradually is that what you were just saying. By making small PR. How much of it is how much of it is currently working then. I haven't really tried it. I just wrote the code for the project plan. I'll be trying to implement it in the community burning period itself. I see. Yeah, I mean, I think I think we'll know how long it's going to take to do all of these things. We have some kind of working test of an end to end. I mean, maybe not, maybe not necessarily converting every single caller but once once you get to the point where you can submit a request with get lab for Jay and get a successful response from the server for at least one endpoint. Yeah, you know once you get to that point. I think you'll have a clear understanding of how long these other things are going to take. But until you get to that point, it's, I don't think we could accurately estimate that. Yeah. So, and that's actually good. Go ahead. No, you can go. So, so I liked how Basel described it as end to end reaching from the get lab plugin, all the way into get lab the server with get lab for Jay feels like a very important, important step and a good thing to do, as soon as you reasonably can right that hey we want that long, that long thin thing that gets all the way into get lab, and that gets comes to the get lab plugin as a pull request, so that we can look at it together. But that will make the pull request quite big. That's why I asked the question on the Gitter channel also that can we have that big kind of full request, because you are saying me that. No, no, you're both correct, but so I think Mark is correct in the sense of wanting to see that code earlier rather than later, in order to make sure that we correct any problems before it's too late. But you're also correct that pull request would be too large to possibly review and merge so that the compromise or the way to blend these two concerns is to make that a draft pull request, which we can start to look at, but then as you make pieces of it, you can create separate non draft pull requests for every piece as you're ready to merge it. And what that will mean is that you're very large draft pull request will start shrinking over time. You can get extracted and merged separately. So the goal is that draft pull request will eventually shrink to a size zero, as all the pieces of it are individually merged, but in the meantime, having it, having the large draft is valuable for others to be able to collaborate and see what you're doing. That's a great idea. I hadn't thought of that I like that very much. Okay, so start with a start with it's okay to go big on the initial draft. But we know we're not going to merge the draft pull request but we'll we can use it for conversation for discussion for education on on my part on others for debugging and exploration. I like that that sounds really great. That's, that's a really great idea. Thanks. So any questions and any other concerns that you guys have. Yeah, no, I wanted to go back and I know Mark mentioned this at the beginning but I wanted to emphasize how valuable I think it is to step through the current logic in the debugger. Before you start testing the migrated logic. I've never, because I've done a lot of migrations like this. And it helps to be familiar with the old execution path, or you start writing the new execution path. And in this case, most of the code in the old execution path is not our code in the get lab plugin. It's combination of our code and this library code. And it's, you know, when when when when you're stepping through the existing execution in the debugger you'll go from Jenkins get lab plugin logic into Jersey and Jackson and then into rest easy. And then eventually into you know something very low level like you know sock API or something. Yeah, just going through that whole path and becoming familiar with it is. And I think it's, it's going to be a valuable exercise. You know, for example, you know one of the things, one of the things that one of the bugs that I fixed in the past has been when the, when the, when the, when the server returns a bad error, like a, you know, for what is it like. When the server returns an internal error. This is like a code path that displays the error to the user and prints out the prints out what the server provided as the result. And I've had a bug in that I've had a bug there in the past where I was close I was reading the response from the server and then closing the socket. And then rest easy was trying to do the same thing, finding the socket already closed and then it was, it ironically was losing the error message because it was displaying its own error rather than the one that I was trying to just so that's the kind of thing where you really have to be familiar with the internals in order to kind of replicate that behavior in the in the new version. And it gets the current code is pretty tricky because it uses Jackson and Jersey to kind of convert these models into JSON. You know, you don't have to study that too closely, but studying the path of how that request gets sent to the server and how the, you know, how the response gets converted back and how errors get propagated, just being familiar with that is, is helpful to have before you go and write work on the rewritten migrated version. So, probably, you know, spending spending a short amount I mean not not a huge amount of time but spending some amount of time just familiarizing yourself with, and don't be, don't be afraid to step into rather than stepping over when you're looking at the code and the debugger, you know, stepping into Jersey Jackson rest easy just getting that bird's eye view of how this whole thing is working is, is, is time well spent in my opinion. So I just answered my debugging question that was I was that's what I was looking for because I was constantly getting into that stapler response and that that crumb thing which I was not liking, but I think that this is going to be frustrating to get into every single detail so yeah I'll try doing that. Thanks for that. So any other queries questions. Well, so one of the one of the suggestions I had seen previously was, you may want to actually configure your own get lab server so that you can, and so that you've got a local thing that you can use for experiments. Don't be shy about exploring that I think that kind of idea. Sure use use the get the public server as much as you reasonably can but don't hesitate to familiarize yourself with get lab itself because you're going to be interacting with it a lot. It's very easy to do that you can you can you can easily set up a local version of get lab because they have a Docker image that. Yeah, using that. Okay good. I have the production thing and the local testing thing both set up so that's not much of an issue for me. Great. No, no further questions from me Basel or Chris any questions from either of you. This looks great. Sorry, there's some questions about timeline. So do we have any draft that. I guess the timeline that had been listed. Is that what you're asking Chris. Because we just talked about a bunch of stuff, but I have no timelines for like what we know which was burned, as well as asking. So the question how, how firm if a commitment is this current timeline, is that we are you trying to see how realistic this is. Yeah, and on top of that, like, I would like to see the time, how the resources going to be distributed across different tasks to see like how much we should include. I don't think it's realistic I tried to create an ideal timeline because I was not able to get the realistic picture of this thing, as Basel actually said that we will have to implement first in a draft we are then only we can say that what time it would take. This is an ideal situation this is not a realistic situation of the timeline that I can say for sure. Do you have like a confirmed list of items we must do and the West like nice to have. I think they must do is our getting getting the entire thing working with with the get lab API and then deleting the rest easy client. There's really much of a. There's really much more after that I mean, if we have, if we have extra time I can think of other bugs to fix but that isn't part of the core project. So the core project is really fairly. There's really only one core deliverable here. Okay. Yeah, that that was my assumption as well as that the. We've we've achieved success. If we successfully get rid of this dependency in the palm file eventually not not now not immediately right you want plenty of time to do it compatibility but if we compatibility remove this dependency. That's a big victory. Okay, I see. And then as far as those dates are concerned I think we'll have a more realistic understanding of how long this will take once we once once we have a working end to end test with rusty with get lab for Jay. And that's so that that's why it's so important to get to that to get to that first draft or first end to end test because that'll inform us. All this other stuff is going to take. Any other question. None from me. All right, then let's I think we can go ahead and call ourselves done for the day. We meet again. Is this time of working a workable time for you harsh is this a good time or is. And Chris is this an okay time for you. It is but it doesn't work for frame and more. Oh that's right we frame frame is only available every other week at this time is that correct. Not not really it's not really on Fridays. Oh, okay. To like to accommodate him. So do we do we need a separate conversation in the chat to find a time that would work for frame I don't remember when frames times work. He was he hasn't made any suggestions. We should ask. Okay, so let's let's do that in conversation in the chat channel to see if we can find a time. I deeply appreciate that Basel was here today want to be sure that we find a time that works for him on the West Coast to the United States so West Coast of North America. And would love to have frame here as well and Chris we want to be sure you're here also. I'm also I'm also fine with asynchronous asynchronous questions as well I mean, you know, especially if they especially if there are debugging issues, if they can be described and writing with a lot of detail that I could just reply to that whenever I get the message, which could be, you know, different the different time. I don't check it regularly but I should be, I mean I can I can join it and and try to try to look for pings occasionally. Thanks for that. And one more thing that I would like to discuss is regarding the. In the GSOC office hours, Chris said to him. What was that I wrote. Yeah, develop the mailing list. Yeah. So what, how are you planning to engage the community more in this project because like something on that sort was discussed in the GSOC office hours. Yeah, so Mark, what's your opinion about this. So Chris is your question there. Do you think that we need feedback from the community I'm not sure where, where do you envision that this particular project would benefit from community is it early testing of prototypes. Maybe not at this stage I'm thinking maybe later like harsh and send an email once once it's ready. And we could have like some data testing done on the github again then, but not at this stage, maybe later. Okay. I'm afraid you might not you might not be able to find too many people who are willing to do that. My experience. I've, I've begged people to make to test changes to this plugin and gotten very few responses in the past so it doesn't hurt to ask, but you might have to prepare yourself for the answer that you'll have to do the testing on your own. That's been my universal experience with the get plug in is I regularly ask, Oh, could you please test this this unreleased thing and yes they'll all test it after I've released it. And they'll test it and then they'll complain that I made a mistake by releasing it before you know, and that's just the nature of it right. I think I'll test it later for the project. So I'll be I'll be a tester. And me too. So that's happy to happy to be involved and as part of code reviews do testing then also so that's that's no shame there but that's us in the project team. Anything else. No, I don't have many questions. Any questions left so I hope you like the project plan. It looks great now. I did have we've got this mentor checklist that I put on the list I wanted to be sure we're okay. Oh, we've got one open question still how your time works out in terms of when you are on vacation breaks, etc. So exams is that already covered in your timeline. If so then we can call that done if not we probably want to be sure that that we know when you're when you're not available so we don't don't get surprised. So I am, I will be missing the coding phase one with my examination from July. I think I wrote it somewhere like less less available to end semester examination July. Oh yes, there it is right there you've done it very good. Okay, so we've got it. I wouldn't even say less available let's just declare unavailable. I don't think so I will be doing some things because this is quite a frustrating project to be honest, I have a lot of errors debugging this and I'll have to work pretty hard on this. Otherwise this can get messy a lot I don't want any regression. So yeah. I actually have something to add because like we got in committed feedback we already have some because if you go to the get a channel. Oh, can we go and tell you about bug you. Because like the mic, like the commenter he actually got back to us saying like that might be like a list. So, like, they want to follow up on this. So if you go to. Yeah, that would apply. So last one. Last one. So you may want to ask him like what kind of issues he has in mind, you may want to work on which he's on. So this is like this. Yeah, he's active. Yeah, that's the primary concern after that after the migration is completed then I will try to fix those but I will ask him related to the blood bugs but I think migration will be much more important than this because But it's good to follow up like maybe. I will follow up. Yeah. Yeah, thanks. I will. That's why I asked you on the data channel as well. Okay. All right. Any other topics. Let's see. So I think we've addressed my concern on the checklist. It is we understand it. We've got it. So I'm going to mark that one checked. Anything else. I'm not left with any questions now. We will plan to meet again next week. And the time will for now be this time, unless we agree on a different time with frame, and we'll do that in conversation in chat. So I can start my code contributions now right. Absolutely. Absolutely. Okay, thanks. All right thanks everyone recording should be uploaded within 24 hours. Sorry for the delay the last time I'll be better. Thank you. Bye.