 All right, so Rishabh, go ahead. So what I was saying was to give useful metrics in that presentation in the DevOps, what is its name? I'm sorry, I forgot. The DevOps event hosted by CloudBees. So to give meaningful metrics, I would need to profile an instance which would have jobs which would simulate a near real-world use case of the plugin. And then we could use the updated Git plugin and with the updated Git branch source plugin to see, to measure the differences in performance in a freestyle job in a multi-franch project. And in that way, for ourselves, it will be a great exercise to understand what kind of changes we are expecting once we introduce this class inside Git plugin, this change. And for the presentation, I will be able to give some useful results. And that would be great for then the project. So we would have to figure out how to profile the Jenkins instance running on your machines because I have the access to the local host 8080 port directly. I'm not sure if I can start the instances using. I don't have the permission. I'm not sure how would I start the instances with. I know how to start them if I am starting them using the war, the Jenkins war. So I can use the Java command to run it. And then I append the JFR optional arguments, the Java Flight Recorder optional arguments. It comes packaged with the JDK 11. So we won't have to add anything else for it. But we do need to run. I only know how to run it from the Jenkins war. For a Docker image, I'm not sure how I would do it, how I would proceed. But that's something we might need to figure out. Because for me personally, if I am profiling it for some jobs, I can do it for some jobs, but not for as far as I know, you have a lot of jobs in that instance, which would automatically be profiled. And we would, I think, have a huge range of data on how the plugin is performing with the changes. So that's what I. Would you be willing to consider not using Flight Recorder, but just using timestamp reports from the build logs? They're only one second granularity. But would that be enough to give us a fast approximation? Then we would just, we can enable timestamper. And I think we could even, in that case then, rely on some repositories we already have that are of known size, like the Git point plugin repository, which I think is less than 5 megabytes still. And the Git plugin repository, which is, I suspect, greater than 5 meg, it's how big? 19 MB, I think. Oh, good. OK. And then we could take Jenkins.io, which I think is about 60 now. And there we've got three. Jenkins.io is around 400, I think. Oh, well, that's even worse. That's even great. OK. So if Jenkins.io is that big, it's even, we've got those. And by choosing those, those are repositories that already have a Jenkins file. And so we could enable a multi-branch project on that Jenkins instance for each of those. Some of them already have it. And therefore, the cache will already be available. We don't even have to have you implement anything in the branch sources for that on that instance, because the cache will already be there. OK. But if we are going to do this whole exercise, wouldn't we want to do both of the things to run it for a freestyle job if we don't have a multi-branch project for all of the cases? And this would not just be for the results, but for the, because I have interactively tested this feature, but it maintains you, the mentors haven't. So I think it would still be, it would be better if I provide the implemented branch source plugin and then we can test. Yes. Yes, wholehearted agreement. Absolutely. Yeah, I don't want to say that we should limit that you don't do it, but rather if you need, for instance, my DevOps world talk has to be recorded today. I don't know when they told you you have to record yours, but I'm in a session this afternoon recording my talk. So I've got to get ready for it, practice it, prepare it, et cetera. And so I thought if you're on a very limited time scale, there may be things we could do to get you the data when you need even faster. But if they haven't said, oh, you've got to be recording it today, no problem. We can do as much or as little as we'll help. Earlier they did say that we have to do it till Friday. And I was notified about it on Monday. So I thought that I possibly cannot do this till Friday. But then I asked Oleg. So he said that we will, since the GSOC students were notified at a later stage, they would give us later dates. And I have booked the recording session for 28th of August. So I think I have a function. You've got lots of time. Wow, you'll almost be done with a project by then. Okay, great. Yes, we would have time. So I chose that date for that purpose. I think I should start the meeting with the agenda. I was, okay. Okay, I'm sharing the screen now. So first let's start with the PRs. We have the first PR, which we are done with is the pull request on the addition of unsupported command in the Git client plugin, which has been merged by Mac. So reviewed merged. You also added the test for it, which I'm very grateful for. So that has been done, that PR has been merged. The second, all the other three PRs which we have, they are the open right now. The biggest one is the get to choose it. And the get to choose a test. The second one is the unsupported command, the usage of that class within Git plugin. I have some work on that PR. The third one is the extension implementation on GitHub BrandSource plugin. So I'm going to start with the biggest PR, the major concern for us, the get to choose it and its test. So there has been a changing design for that PR and the reason for that changing design is an observation, brilliant observation by Omkar and Fran. They both pointed out a huge, I would say a hole, a gaping hole inside the get to choose as implementation and I will go through what is the problem and how have I solved it. I think I've added the comments in the commit message and I will just show that and then explain what the decision, the changes. So currently, so we are talking about Git tool here. Git tool is basically a class which is encapsulating the details about the Git implementation which is going to be used to create a client in the Git plugin. So currently a Git client, we know that a Git client is initialized with a Git implementation. Now there are two decision factors which decide what implementation will be used. The first is the user, the second is the system. The user has an option to choose decide between get, jget or jget Apache. These are the three options they have and if they do not choose, we provide the default implementation as the Git implementation if it is available. If it is not available, we have the jget implementation shipped within the plugin. We would provide that. The second decision after the user chooses its implementation, its preferred implementation, the second decision is taken by the system. That is that it takes the user's choice and then it validates with the particular agent or wherever the system is working to check if that particular user's choice is available within the system or not. Now what is happening with the introduction of Git tool chooser is that we have added another decision variable to this whole process of providing the implementation from the user to the client, to the process of making the client. We've added another decision variable which is the Git tool chooser but the Git tool chooser was not considering what the system is evaluating and then providing the implementation. What the Git tool chooser was considering was that, okay, I will tell what the best implementation is but before telling that, I will check if that implementation is installed or not but we are not seeing what the system has already provided and shortly we will see how that will break some use cases existing if we do not take into consideration what the system is providing to us. So the change in design is basically what I'm doing is that I'm in the constructor, in the initialization of the class, I'm adding another argument which is the executable path of the implementation which the user has provided. So how this works within the Git plugin before the Git tool chooser is that the user would provide for Git, for Git, the CLI Git, user can provide the name of the implementation and provide the path within the system that is how it is installed. So the Git plugin uses the path provided by the user. That is what it uses to feed the Git client initializer and then it initializes the Git client. That is how it works. So what we need is, we need that executable path and then we can decide if what we have to preserve, what, how our decision is not affecting the existing case and I think the best way to understand that is, let's just look at the test cases I've added so that those are the scenarios where we can understand how this is affected. So I will, okay, this is the test class, yes. So we have two scenarios here. The first scenario is the size of the repository is less than five and the Git tool chooser will recommend JGit. Now, this is from Git tool chooser side. We have some decision variables we have to consider before that. Those are, let's say the user has installed the installation is called MyGit and its path is set has to be user bin Git. Earlier, if user was providing this path, I would not consider it. I would just say, okay, give JGit because the sizes less than five and the Git tool chooser would provide JGit, but let's just say that we, what if there is a scenario where we have to use Git but we are not using the path for it. We are giving the name for it. And maybe that works here because it is linked. So Git would work in a system where Git is installed in user bin for a next system, but it might not work if there is a difference, if it is installed at a different path instead of the user bin, which might be unlikely, but it's still a case I think. Please interrupt me if my assumptions are wrong. So if this is the case that the user is installed, the Git tool with a different name and a different path, what we would do is, so what we should expect is in this case, we don't have JGit in this system, although we will always have JGit in the system, but for this particular use case, I have removed this Jenkins instance all only has the Git tool, which is the MyGit tool, which is configured by the user. So the tool now will recommend user bin Git instead of, and it should recommend JGit because the size is less than 5MV, but we do not have installed JGit in the system. That is why it is not able to provide it. So this is the first use case. Now the second use case is what if we have the same Git installation and we have JGit within the system, then I think the expected behavior is that it should provide JGit as the expected implementation. And one thing I am missing here is that while writing the Git tool chooser, I did not investigate the fact that we should not provide the implementation name, we are providing the path where the implementation is installed for the Git client. The Git client does not take the name of the implementation. It takes the path of that implementation. That only matters, it is limited to the scope. For JGit and for JGit Apache, it doesn't matter. The path is same as the name. That is what I have seen in the JGit tool class, which is implemented on the extended from the Git tool class. For Git, it matters because the name and the path where it is installed can be different. So this awareness, which I did not have earlier to the observation by Omkar and Fran, was something I now realized. And that is why the Git tool chooser is now aware of that fact and it will provide the path instead of the name. For JGit and JGit Apache, it will still be the same. It is equivalent to the name, but for Git, it will provide the path instead of the name. So I have some more use cases where I was not... Yes, Mark. Okay, so I think the test that you've got on screen right now, the top of the screen indicates a potential problem if this test is passing. Oh, no, no, sorry, not the one down. So the next one down, the one that uses JGit Apache. Okay, so excellent that you wrote these tests. This is brilliant. Thank you so much to Fran and to Omkar for detecting the problem. The, in this case, oh, oh, no, okay, I see. So in this case, you've got command line Git, and JGit Apache, and it chooses JGit. Do you have a test which has only command line Git and JGit Apache? No, I don't. I have one with only JGit Apache, but I don't have one with JGit Apache. Okay, so long as, so it looks, if you've got the, well, if you could just safety check for my comfort, that if CLI Git and JGit Apache are both available, but JGit is not, JGit Apache should be chosen because it is a plug-boom compatible replacement for JGit, right? So you've got the case at line 300 where you are correctly choosing JGit Apache. So that's a big win. But yes, I actually, so what the decision I took was that if we have JGit and JGit Apache, I would use JGit, I would not use JGit Apache. And that is the correct decision. That is absolutely correct. If we don't have JGit enabled and only have JGit Apache, we should still choose JGit Apache for small repositories. Yes, sorry, sorry, please. No, no, they are functionally equivalent except for some relatively subtle details in terms of the authentication protocols used talking to a remote HTTP server. And I have missed that case. I just realized that if I would have JGit, if I have to recommend JGit and available installations are Git and JGit Apache, I would recommend Git. I would not recommend JGit. Okay, so then your tests have exposed a case that I think we want handled differently. Good, very good. Yes, I have noted that case and I will implement that as well. So these are the scenarios. Yes, Omkar. JGit is always available for JGit installation or no? No, no. Well, it's not always enabled. So the user must... I can disable it. Right, it is by default disabled. And because it is by default disabled, it is not in the descriptor list as a set installation. So the tests that, now it's actually the code is available, but because it's disabled, they have to choose to enable it in order to get the benefit. And so this was the scenario when the Git 2 chooser has a repository of size less than five MB. Now, if the scenario is that the repository size is greater than five MB, CLI Git should be recommended. And I think the cases, again, they show us that if we have no tool installed in the Jenkins instance, I assume that the Git executable would, can be named, so it would be named Git, not since the user has not provided the path. So then the Git 2 chooser would recommend Git. And if there is a case where JGit is installed and Git is not installed in the system, and it has to recommend Git, but since the system doesn't have Git, it would provide JGit. It's just, I would say an exhaustive list of the possible scenarios we could have. And maybe they do not make sense in a lot of cases, but it's a possible scenario we could have. So on this one, can you help me understand, or I can ask separately, what do you gain by the reference to the credentials which are here? The sample repo in it? Sample repo in it is for the project I am building. So I, for this, so I need two things. So since we have enabled authentication now, authentication, we provide credentials to the plugins who will implement the extension points. We need to send them two things. And the first is the context of the job. And the second is the credentials ID. So to build, to have the context, I need to build a project so that I have a context. And so that is why I am initializing a sample repository and then I'm building a project. The function is given, it's the latest part of the code. And the credentials, I saw this in one of the tests already written in Git plugin. This is a way to, so initially before the test start, I have at the rate before a method which would initialize a local credential store. And it would have a credential called GitHub with the ID GitHub and a username password sample. And what would happen, what I expect is, I actually expect since so we, so our responsibility is to provide the credentials ID in the context, it's the plugins, the other plugins responsibility to use them and to validate in this particular test class. I have test extensions. I have implemented those extensions just so that we can use them. But I haven't included any logic which checks those credentials and validates them. Because that is, that would be the responsibility of the GitHub branch source plugin. And I'm not sure if there's a point of validating them through our logic. I am not sure if we should do that right now. It just checks if the current, if the repository URL contains GitHub or not. That's the, it's not the right logic to check it, but it's just for this test class. So that is why I am building a project so that we can have the context and then we have the credentials we provide to the Git tool chooser. This is the second point, the change in design I wanted to discuss. I discussed the implementation part first, the Git tool implementation part. So you can look at the test cases and we can see how, what cases I've missed. But this is a big change which I missed while creating this class in line. I have added it currently it's pushed. I locally built it in my system and it is the tests are running fine. So I've missed one case which Mark has pointed out. I'll add that shortly. And I think for this change in design, this is what I wanted to say. Any further questions on this particular change? Any concerns? Possible concerns I've missed or maybe if you later look at the PR and review it then I think that's the better way, right? Okay, so the second thing is the authentication is basically providing user credentials to the plugin. Now, with this change, we have certain issues I want to discuss. The first is that there are multiple ways, multiple credentials, multiple ways a user can create credentials and from Git plug-ins perspective, we have I'm not just maybe more than two or three valid ways of creating user credentials. But when we provide those credentials to the GitHub branch source plugin, the GitHub branch source plugin will only consume username, password type of credentials and it would not consume any other type of credential we may provide to it. So that will limit our, I would say it would limit the cases we would cater in terms of optimization. I could not find a way around to, so there was one possibility suggested by a month that maybe the Git branch source plugin maps the URL, URLs with the credentials. So if I provide the GitHub branch source URL, a valid repository, remote repository URL, it could possibly look at the credentials it might store. But again, I think for that, a user in a Jenkins instance, the user would have a GitHub organization project and would have to set up those credentials. That is the assumption we took. But I cannot find any way where only the repository URL is enough to get the credentials. What I'm seeing is we need the context and we need the credentials ID. So that is a concern. I'm not sure if there is a way to expand the type of credentials we are sending. Also, what I saw in the GitHub API, the Java API implemented in the GitHub branch source plugin, just a second, I'm not sure where. So just a point of reference, I think we were putting the credentials in the Git plugin to support freestyle projects, right? That's the primary reason why it's in the Git plugin. So like GitHub branch source would already have its own credentials and a project would have been configured to project credentials for that project, right? A GitHub branch source plugin, a project, yes, it would. But then, okay, so I have a question related to that statement. If someone is configuring a project using the GitHub plugin, branch source plugin, it will not be needing the Git plugin for any, for the branch source, for scanning the branches, or for, because as far as I've seen the code, they have implemented their own SCM APIs. They wouldn't need a credential from the Git plugin. They would not, but then they would not be able to, we will not be able to actually use that, use the performance improvements because the Git plugin will not be used in that case. If we just have a Jenkins instance where a user has created a project using the Git branch source plugin, I am not sure the optimizations we are talking about, they will be used because the GitHub branch source plugin has its own SCM API implemented and it would not need the Git plugin for any case. Or am I wrong here? I think for the cloning activities and stuff like that, it still uses all the Git plugin stuff, right? Or, actually the API stuff, I was primarily for like, hey, do I have new branches? Hey, are there other things going on? They're also doing like the reach out stuff that we're trying to do, like the estimation. That's all the API driven stuff, but I think all the, Mark, Mark can go ahead and he knows better than me, probably. Justin's got it right, that when a branch source needs to ask REST API questions to, as part of a multi-branch pipeline job, for example, it uses the credential that the user provided as part of the multi-branch pipeline job definition. But when it comes time to clone a repository, it goes down to the Git plugin and says clone the repository for me. But then it provides the credential that it has to the Git plugin. So I think that supports, Rishabh, your assertion to Git plugin has to be willing to provide the credential out to others who may need it, like the branch source. But I wouldn't need the credential, right? Cause it would already have one of its own for scanning. Well, I think the flow of information is that the scanning has a credential, it passes that credential down to the Git plugin. The Git plugin can use it for clone purposes, but if the Git plugin, since it has the credential, now needs to ask a question related to, hey, give me the size of this repository, the estimate of the size of this repository, it can hand that credential back to the branch source and say, here's the credential, use it. So it doesn't, I think it's a simple approach as what Rishabh is planning to do, pass in the, pass back the credential that the Git plugin got, however it got it. I see, this is just flow control within the guts of how they're interacting. I think so, yeah. Okay. But if there's a case, what Justin has just said, if there's a case where we have a multi branch project configured by GitHub, so GitHub has the credentials, and then it is passing those credentials to the Git plugin to clone, and then we are again passing those credentials, we are not those credentials, would we be passing the same credentials? I'm actually not for me to understand that, I think I need to understand the credentials API better. So the credentials store, which stores the credentials, would it be common for the Git plugin and the Git branch source plugin in the same Jenkins instance? As far as I know it is, there is the credential store is shared by, as far as I understand it, all the components inside a Jenkins instance. Okay. So there- That's pluggable. You can have multiple credential types. Okay. So there must be a way for us to, if we, so we could maybe add a functionality before sending the credentials, we could check the store and, but how would we know that we have credentials for this particular case? Well, in fact, for GitHub branch source, I believe it also requires that you have an actual username password credential. I think that's a limitation of that plugin. You can't do, like, you need scanning necessarily by username password because you can't do scanning by an SSH key, for example. That's what I saw has been. Yeah. So I mean, you kind of have a guarantee that you have a credential that, unless it's anonymous access, you kind of have a guarantee that you have a credential that can reach out to the API from the GitHub branch source configuration and project. Okay. So then I would need to create a function which would check the credential store for a use. I'm not, what I'm not able to figure out right now, maybe I need some more time to understand it, is that how would I uniquely identify those credentials from the perspective of Git plugin? How would Git plugin have that information? Or maybe the Git plugin would have that information because the Git Transource plugin has passed down that information to me and then I can use it to check the store. Either that or the GitHub branch source plugin provides you an answer based on the results of the query. Either one of those would work, but I don't think Git plugin would know that or have a way and probably shouldn't reach back into GitHub branch source to try and figure out link mappings of things. But the Git plugin can look at the store and if it has the credentials which are passed down by the GitHub branch source plugin, it can use them if they are mapped with the store. Yeah, I guess I'm wondering what the Git plugin would even do with those credentials. Wouldn't the GitHub branch source plugin do the work? So the problem is that if we need to send when the extension we are implementing, it's a static class, we need to initialize a GitHub object, which is basically it encapsulates the APIs we have for GitHub Java APIs. So it needs the credentials. So at that point of time, it needs the credentials and I cannot take those credentials within the GitHub branch source plugin because that would mean that I have to provide a non-static object to a static class. So what I understand, what my understanding is that the extensions, if they are static classes, we're not meant to take information from the individual objects of that particular instantiation. Or maybe there's something I'm missing here. My question is, I thought about using if the GitHub branch source, initially I thought that if the GitHub branch source plugin has the credentials, why not use them for the extension? But how I was limited there was that the extension is when I implement an extension point, it is a static class and the credentials ID for a particular user credential would be non-static. That means for that particular instance, how would I communicate it with the extension within the GitHub branch source plugin is what I could not figure out at that point of time. And the second thing, my confusion was the context. So what makes sense is that the Git plugin should provide the context where the branch source plugin should scan with which the branch source plugin should scan the credentials because the Git plugin is using those functionalities and the job, which it is running, should be the context it is providing to the branch source plugin is what I understand for scanning the credentials correctly. So... I think that's the other way though. I think GitHub branch source is gonna inform Git plugin of context, right? Ignore me. I think I'm wrong. No, I'm just trying to understand because frankly, I don't have a good knowledge of the credentials API. I just learned enough to implement the scanning abilities, but I don't have... I think I need to study more how context and... I think off the top of my head, I think it's fairly normal if you need to use your credentials ID in a plugin that you would potentially get that credentials ID, get it within your context and then use it. So Justin, you are right here, but my issue is that I want to show you the issue through code. So the estimator, so I've created this extension inside the Git branch source plugin. Now, this is a strategy class. How do I access the context of the current branch source plugin and its credential ID and provide it here where I'm trying to connect with GitHub, the GitHub APIs, and then retrieve the size of the repository? How would I transfer that information within the plugin? What information? The context... So if you're talking about using the context provided by the GitHub branch source plugin and the credentials ID of that plugin only, then we need to provide those two parameters to this extension where it is trying to query the size of the repository. How would I... So right now, how this thing is working is that these three parameters are being provided by the Git plugin to the Git branch source plugin and then it uses the context and the credentials ID to scan for the credentials. Once it finds them, it creates a connection and it gets us the size. That is how this is working. But if we are thinking of use, if we know that if there is a project created by the GitHub branch source plugin, then we would have the credentials within the plugin. Then how would I use its credential ID and the context for this extension is something I am not able to understand, couldn't you? Yeah, that one might be a particularity depending on the plugin itself, maybe. I don't know if there's... Are there common patterns? Do you guys know if there's common patterns for some of these on how their credential IDs are attached to their context? I would think you would need to use your item context to retrieve that from the branch source plugin itself for any instance. Yeah, I confess, I don't know. I thought that Rishabh, this was working the way you had hoped and so I'm not seeing the compelling reason to change what this is doing right now. It is working, so we are getting this size for... I have tested it with a private repository and a public repository, so if I configure the Git plugin to use a username password credential, I am able to retrieve the size and I am able to run the Git to a user as expected but the whole discussion started from the issue that we are narrowing our scope of usability once we are only limited to the username password credential, but I think that that's not a choice we can make, it's what the GitHub branch source plugin supports. And then, so there was a possibility discussed by Justin that what if we use the credentials in the context within the branch source plugin that would make us less dependent on what the Git plugin is providing and because we know that the GitHub branch source plugin would definitely have the credentials if it is being used in the Jenkins instance. The Git plugin might have it or might not, even if it does have the credentials, it might have the type of credentials which are not supported by the GitHub branch source plugin, so that is why if we are passing down the credentials from the Git plugin to the Git branch source plugin, that is how the current flow is working, we are limited to the user's choice of using username and password credentials in the Git plugin. So the problem is that the user might, they will not know about this performance improvement, will not know that using the username password credentials would actually enable something which the user doesn't even know. So the point is that if the user is using the GitHub branch source plugin, the user will be forced to use username password credentials and would add that in the Jenkins instance. But if the user is, if we are looking at this problem from the Git plugin's perspective, from a user who is only using the Git plugin and not aware of the GitHub branch source plugin, for that user, he will use whatever way of credentials, whatever type of credentials they use and it may be username password, it might not be. For us, it will only help if it's username password credentials. That's what we're doing. Yeah, I think the primary challenge is going to be usability for getting a branch source. Like, if you think about how you would maybe need to set that, because maybe I'm not understanding this correctly on how you set this up for Git plugin and how this would look. But I think if I'm understanding this correctly, if you're setting up a multi-branch project or something like that, you would select your credential for your multi-branch project and then you'd also have to, like we would have to warn people, select the same credential that you picked for your branch source so that it aligns in terms of username password and token. Right? That's your concern too, right? Rishabh? It is, but then that's an added responsibility to the user of Git plugin who doesn't, who is not aware of the performance improvement. It's supposedly a hidden feature. User is not aware of something. Wouldn't the user think about why is it happening? Why would it? I'm not sure from the perspective of user how it would go, but then if we have a multi-branch project, we wouldn't even need the credentials, we wouldn't need this API, we would have the cache. So I think if we have a multi-branch project, we would not have to worry about querying the size of the repository via a REST API. So I think this needs more thinking and probably to clarify, to have a clearer discussion, maybe I can make a diagram with the current flow of authentication, how the Git plugin is expecting how the size, how is it working so that then maybe the mentors can review the diagram and the current implementation, the way it's working, because the PR has had, I think it's greater than 16 messages, it's a long conversation, it might be difficult for people who haven't reviewed it yet. So I would add a diagram to it, attach a diagram with the current flow of authentication. And in meanwhile, I'll think more about how... So currently it's a non-blocking, this discussion is non-blocking to the Git tool chooser's release, if you're talking about that, because the Git tool chooser expects the size of a repository from the REST APIs, it is able to do that. Conditioned that it needs a username password type of credential, but if we have that, we're able to do it. So we can say that we support that currently, but meanwhile we can look into how we can expand that scope of usability here. Yeah, because I mean, I guess you have a couple of pieces of work and I think to Mark's point, if this works for now, you can refine the extension thing as its own probably, because the Git tool chooser for Git itself seems like its own big chunk of work that we've been working on for a while. So I think if this works for now, like probably refining the extension seems reasonable. Yes, so... Mark's thinking. So currently after this discussion and the changes I've done, the status of Git tool chooser is the interactively, I have the current changes I've done, I've tested the Git tool chooser with multiple implementations and in the case of a cache, cache repository, if we have that, then it should use that to estimate the size and I have also used a modified version of the GitHub brand source plugin, which is local in my instance. And I've used that to interactively test that the Git tool chooser is able to recommend the optimal implementation while we are checking out a repository using the Git plugin. So I have been able to done that the next step after the review we have for the current changes is for me to instantiate to add the Git tool chooser everywhere the client is being created within the Git plugin. So I haven't done that. And the reason was that I wanted Git tool chooser to be a functionally working class before we decide to add it at places. It should work how it's supposed to. And after I think what Justin and Omkar pointed out, I assume that we're, and one case I missed which Marcus pointed out, I will add that. I assume we are code-wise we are done with Git tool chooser. But again, I think the mentors need to review it first. There might be things I've missed. There are more test cases I have to add. And those are related to unsupported extensions when we're using that in the environment. Unit test cases do not cover those cases where we are using unsupported extensions and JKit should not be recommended for those cases. So I have to add those test cases. Test cases-wise that is what I haven't added for the current change which is using the existing, the system-provided path, Git executable path and then deciding to implement, to recommend the implementation. I've added those cases. I've just shown you the cases that the latest commit in our PR number 931. Apart from all of this, I have one more thing I needed to discuss was the extension work. So that is something I am doing parallely. And I have been working with Liam on merging the PR for the GitHub branch source plugin. I was stuck at creating unit test cases for that because I think it was hard for me to mock a GitHub web server and then ask for, so what is happening with my test cases is that it's actually trying to contact the HTTPS GitHub API server. And that is creating a problem because the credentials I'm providing are they're not correct credentials. So I'm stuck at that point and I think Liam has told me that he will help me in writing those cases. And once I'm able to mock that, then I think those test cases are done and we will be able to, I have since I'm talking about the extension, I have one more issue I haven't discussed with the mentors is that, so for the GitHub branch source plugin, Git plugin is added within that plugin via the GitHub plugin. So the Git plugins dependency is not directly exposed in the form of the GitHub branch source plugin. The GitHub branch source plugin contains the Git plugin using the GitHub plugin. It comes with the GitHub plugin dependencies. I checked the dependency graph for the GitHub branch source plugin and that is how I got to do that. So now my problem is that I want to use a class of the Git plugin which is not available, which the GitHub plugin does not have because it is depending on a 4.2.2 version of the plugin. And so my concern is that if I directly add the Git plugin, the latest version, the snapshot version I have to the form, it creates the enforcer issues, upper bound dependency issues. And so I was not able to solve it at that point for, so I did a very bad hack. I just replaced the jar of 4.2.2 with my updated jar in the M2 repository and that is how I'm working with it right now. But I suppose that is also a concern I have with that plugin and yes ma. There is a trick used inside the Git plugin where it has an optional dependency on some other plugin. I forget which plugin it is that's optional matrix plugin maybe. And inside the source code it does a dynamic check to ask if an API is available. That might be an option here at least short term that you can use reflection to ask, is this API even available? It's uglier code, it's less attractive code. It's much better if you can update the palm to say I depend on this newer version but a reflective check, is this API even available? Is used in some other places? Okay, okay. I know the thing you can do is try and get a local GitHub build and bump its dependency and then bump to that GitHub version. Right. If you're just trying to get infrastructure and getting this going. But then ultimately when we are, even if we release the latest version of the Git plugin, wouldn't we would have to go to GitHub plugin repository, the maintainers and then update their version of Git plugin so that we are able to use it in the GitHub Brunswick plugin. Yes. Yeah, what I suggested is probably your next PR. You'll have to change it anyways. So you'll have to send them a PR so that might actually work out well for your local testing. And you'll also be kind of like testing out that PR as well if that works for you. Perhaps you need what Mark's suggesting to you. But you'll have to do that at some point. Okay, so. So for me the task right now, the first is to add the case I've missed which Mark pointed out with the implementations that if we have Git and JGIT Apache, we should recommend JGIT Apache and not just look for JGIT. That is what I have to add. And the second thing is that functionally I'm done with the GitHub Brunswick plugin extension implementation. I think I can, I will wait for Liam for working on the tests but the classes is done. And I will move on to the GitLab Brunswick plugin or should I move to the GTI Brunswick? Is there a preference to which Brunswick plugin we should move on to or? I would guess personally that the GitLab Brunswick plugin is probably more popular but you could check stats.jankins.io or plugins.jankins.io to see here. Actually, I'm just gonna do it. It's easy to ask the question. How many installations are there of the GTI plugin? Okay. There are 1,700. How many are there of the GitLab Brunch Source plugin? There are 4,000 of the GitLab Brunch Source plugin. So just based on the count of installations, GitLab Brunch Source wins. Okay. And actually, if you're already talking to Liam too, I wonder if he would be able to give you an opinion on the credentials thing or GitLab Brunch Source. Yes, actually, I could not, I should ask him, yes. And I'll ask him when I'm having the conversation with a good test, I'll ask him, yes. Yeah. Again, don't need to completely couple this all to, especially GitToolChooser and stuff like that but that seems like a good thing to answer for the extensions, especially as you move to other branch source plugins because you might end up using similar patterns. Yes. Agreed, agreed, Justin. That's a great advice. I'll do that. Because I think it's best if we resolve the authentication discussion before moving on to other Brunch Source plugins because if we do not, and then we have to change the GitToolChooser for some reason, then we would have to change all of those Brunch Source plugin extension implementations as well. So yes, that's a valid point. It's still reversible at some point. So don't worry about if you make a mistake or something, we'll do that. Okay, so I think I've taken a lot of time today. Double of what we usually take. Thank you, everyone. Before you close, I've got one more open question. Any objections to a release of Git Client Plugin 3.4 so that we have a published version with the unsupported command in it? Good. Okay, no objections. I'll go with it. Thanks. So it'll probably happen within the next day or two. Okay, great, that's it. All right. Thank you, everyone. Awesome. Thanks. Bye.