 Yes, I'm going to share my screen. Hi, everyone. Today's agenda. The first thing is, okay, so I've done some interactive testing with some unsupported extensions. I've tried adding those extensions and to see how our GitToolChooser is behaving when those extensions are added. And specifically asked for those results. We were having a discussion in the PR. So I think we can run a build and see it in real time. So in this project, I have a very small repository. It's under 5MB. So should I go to the configuration page? So this Jenkins instance contains both Git and JGit in its environment. I've specifically chosen JGit as the preferred tool. And so right now I have an additional behavior. I'm going to delete it and then I'm going to run this, build this project. So what should happen is it should prefer JGit and the recommended tool should be JGit by the GitToolChooser since the repository size is less than 5MB, which is the expected behavior. Now as we go to the project again and we configure the project and we will add one or two extensions, additional behavior, which are not supported by JGit. So now after adding those extensions theoretically, the GitToolChooser should not recommend JGit. It should recommend Git. That is what it should do. So timeout is also a feature which is not supported by JGit. So let's just save this and I have to delete to wipe out the workspace. Now why do you have to wipe out the workspace? Because if I don't then it is not going to check out the, not going to go through one of the functions I wanted to go through. So if it's available then it doesn't, it applies a different operation, right? So yes, here the recommended tool is Git. So I tried this with, right now I've shown it with timeout. I tried it with clone behavior where I included shallow clone. There also I saw the same thing. So I would assume that functionally the unsupported command is working how it should and the way we are taking that information, it's working how I expected it to. Now I think with this current feature unsupported command and the GitToolChooser what remains is testing in different scenarios. I would say would you recommend an exhaustive list of all the extensions which are not supported by JGit and then testing all of those extensions before and after cases? That is what we would want for each of the extensions which are not supported in JGit, right? I have done it with two or three. It certainly seems given how many people are using the Git plugin it seems safest to check as currently if there's an option in the plugin it's probably not only been used but likely misused and so I'm prone to say yes but I'm open to other discussion or other saying oh no, test 50%, test a random selection. The spot checks you did are great. I would love a broader check personally. Okay. Fran, your comments, your concern? Because you're asking a very valid tradeoff question. We're trading time to do interactive tests for other things, right? It's a valid tradeoff question. Okay. Yes, Fran. Sorry. No, no, no. I was about to say that. No, because most of my questions were all about the question that with your test have been answered. So now I have a clear understanding of your PRs. So now what I want is to review again the PRs and be sure that now I have all the information and I'm in a better position to review all of them. Okay. Okay. So the second thing is a change in design. So now what was happening before the change? So for Git tool chooser, we had two constructors. The first one used Git SCM source object to get the cache and it relied on the source, Git SCM source object to get the cache and the second construct and this constructor, so what we did was first we looked for cache if we could find it and we estimated the size and recommended the tool. If we could not, then we looked for extensions and then we asked for the size from them and if we could find that, then we could recommend the tool. Now, the second constructor I gave was an option if we just have the remote name and nothing else so that it can be used across other projects apart from multi branch project. So now Mark suggested that we should not need the Git SCM source object to get the cache entry and I did find that that we would only need the remote name to access any .git directory cached within the Jenkins instance workspace. So now we don't need two constructors, we just need one constructor which would require the remote name and then it would make the decisions. So it has two ways to find the size. The first one would be the best way we have is to determine it using cache and if we don't have that then we use the API, the REST API method. So I ran the unit tests again on this to make sure that the code is working with just the remote name. It doesn't require the source object and it is working well. It's all the cases have passed so I don't think we would need much. I would, I haven't pushed this code on the PR yet. I just wanted to show you first. So I think this is it with the design modification. I think we would need more design modification. I'm coming to the third point now. So that is related to the support of other extensions. So I've been looking at, so the first question I have with the support of other extension plugins is do we first, in our first go, do we want to only support public repositories and size related to public repositories or would we want to, okay, so we want both of them. So for that, I asked in Gitter about user authentication and Mark suggested that it would be best that we allow get the branch source plugins to decide what kind of credentials it should use to authenticate the user and then use the API to get the size of a private repository if it wants to. So with that approach, I was looking at the branch source implementation. I have some concerns. The first concern is that, so the way the branch source plugin is going to pass the credentials or get the credentials is same as I found in the git plugin. It's using the lookups scan credentials functionality. And so it needs three things. The first is the context that I assume is the job which is running. The second is the API URI, which is what we're providing. The second is the credentials ID. So as far as I understand, the two things, these two things is something we have to provide to those plugins. This is not something we can take from them because what I've, so yes, yes. One question about the credentials. Why is git client who has to provide that credential to the other plugin? I don't know exactly what is the, how other plugins are using the plugin in for the concrete case, okay? That's what I am asking. Because my understanding is that, ah, no, okay, no, no, no, no. Okay, no, no. I got it. I got it. I got it. Nothing, nothing. Sorry. Sorry for the noise. No, actually, I tried that. I tried. So my first implementation approach was to use the context they have or to use the credentials ID because I thought that if the source plugin is installed in my instance, I can use the context and the credentials ID. This project would have, but that would be, that would not work, but still I, so I wanted to do that. But then I figured out that I found that the extension is implemented as a static class. And all of these, whatever objects we are trying to access are non-static. So first of all, I could not figure out a way to get them in that I don't understand is that, is that possible? Because if the, if these are static classes that, that means that they're going to be shared across all the objects, which is not, which doesn't make sense with the credentials ID, because that would be linked to a particular object. So that's what I understood from it. So I thought that it would be best for us that the Git plugin, while it's asking for a particular size for a particular repository, should also tell what project it is. I have a very limited understanding of the class called item. That is what it is accepting item. Item is the context it wants. And then the credentials ID is something we can provide. And then we can, then it's, it's the job is, I think is easy. But now the question I have with this approach is related to the item, the job. So right now, when I did not pass any credentials, I, my, the Git plugin was, was, was using, so I was using a freestyle project. And I, and I used the API extension of BrandSource without using it, using it anywhere that, so my, my question is, if I want to pass it credentials, which means that I'm passing it a context, does the plugin, which is the BrandSource plugin, needs to be, needs to be used in a project. Is it necessary for it to be used in a multi-branch project? And if it's not being used, it's just there. It's inside the Jenkins instance and has never been used. Would it still be able to accept the context I have and use it to scan the credentials and connect with GitHub? Or am I? I think it's an excellent question. I don't know the answer, but I may have a specific example of a case that will, will likely fail and, and need some more thought. So, so if, imagine a freestyle job that is a credential, a job with a credential that uses an SSH private key as its credential. Okay. All right. So that's the credential ID we have. And now we ask the SCM repository scanner from the BrandSource plugin to scan with that credential ID. It can't because REST APIs are not secured by private keys. They're secured by username password or by tokens. Okay. And so, so I think, I think your, your question is a crucial one. And I don't know the answer to the question. I'm hopeful that the BrandSource plugins will see the dubious credential ID, ignore it or, or bias towards choose a credential that they already have associated with the, a particular repository, but I don't know that for sure. Okay. And that is something I, because they, they do validate the API you, you arrived provide. So I haven't looked at how they're validating it. Maybe they are doing what you are suggesting here. I guess it's the problem we're trying to solve the, to, to allow this for freestyle jobs. Is that? Well, it's to allow it for anything because we, we want the tool chooser to not, to not require that you must be a multi branch pipeline. Right. The tool chooser needs to benefit everybody. We would, we would like it to benefit everyone. And, and therefore if, if it can ask the question viably through the BrandSource, great. Ask, ask the question and get the answer. So what I can see from how they're validating their API URL, they are checking if the credentials is an instance of standard username password credentials. If it's not, they are throwing an IO exception saying unsupported potential type. Okay. So that you've already answered the first, first observation I had, if we inadvertently pass a private key credential to this, check API URL validity will fail. And that means that we will not be, okay. Right. But that's, it's, it's perfectly, they, they may not have anywhere in their system and a token for the branch source, right? They may have just installed the branch source and have no, no username password assigned to it. So, so failing is a valid, valid behavior. So then, I guess the other thing is how would you, how would you associate, I guess, are you doing a lookup on the, on the URL to determine that it's GitHub? Because the branch source plugin, I think it knows that it's GitHub because you're, you're, you've configured that as part of your multi-branch project. So in a freestyle context, like how would you know that you would talk to the GitHub branch source plugin versus the GitLab branch source plugin? I thought he just asked every, I thought you were just asking every provider, do you have one? Can you answer me this? Did I misunderstand, Rishabh? Yes, yes. That is what, so we've exposed a method which is this, is the URL applicable to your plugin or not? So if they, so then in that process, they can validate it using the API you are validating this method or whatever they would choose to. So then my question is, so for, for example, what I, so what I experienced while I was sending an unauthenticated request was that I was in a freestyle job, I was able to get the size of the repository without having a cache. And I did not have a multi-branch project within the Jenkins instance. It was just the only project. So with authenticated request, we would need to figure out a way that credentials are either the username password or they're a token. That is, those are the two types of credentials which would be supported by REST API. So, so then, so if the freestyle job but is configured by the user as with the private SSH key, then we, we cannot do anything about it, right? Right, I don't think, well, no, maybe that's too strong because it's, there are some of the branch source plugins that have, have various mappings that attempt to, oh, you asked to use this SSH key and I have a username password pair that I can use whenever you mention that. So, so there's at least one branch source that says, hey, I can do a checkout with private key but still use this username password pair for, for token-based access for, for REST API calls. So I'm not sure that you should optimize away the call to the branch source. We should ask them and let them say no. Okay. Okay, so, so then, so then when we are sending the repository URL for which we need the size, we, but we would send the context and the credentials ID. That is something we have to send. I think you're right. I wish it were different, but I think you're absolutely right. The thing that knows that I had the flawed idea earlier and it was obviously completely flawed that G, the branch source should just know the credential it will use, but really it can't, right? Because it has to know, has to know the URL and has to associate the, the credential with the URL. So I think you're right. I think we're going to have to pass it. Or maybe I haven't explored the branch source plugin in any of the branch source plugin where it cannot contain a map, could not create a mapping between the repository URLs, URLs and the credentials it has stored. It would, right? It would create a mapping. So if, if I am, if I'm sending a repository URL, it would be able to check if it contains the credential. Yeah, it's, it's certainly worth exploring, right? It is absolutely worth exploring to see, do we really have to pass a credential? But I suspect you're going to find, oh yes, we have to pass a credential. And I guess I'm kind of wondering like, because you wouldn't want to accidentally pick up the wrong credential either because that could like lead to credential leaks. Right, right. That's a novel one, right? Oh, I asked to scan the super secret everybody's passwords repository and I just borrowed the credential scanning the credentials from, from the Jenkins system. Yeah, I wonder if you need, like if it ends up not being a if it ends up not being a token or username password, like I wonder if, like for a freestyle job, if you'll end up needing to provide an option for the user to select their REST API credential, something like that. I don't know. Anyways, I look at the PRs, sorry, I'm behind too. So I'm, I think I'm slowing us down. That's okay. So I, so what you're suggesting is that if we, if we know that the credentials the user has passed would not be able to use for the REST APIs, we would ask the user if they can provide. Yeah, for me, that's, that's a very exotic case. I wouldn't worry about it, Rishabh. It's this is, this is just a heuristic, right? We know it's a fallible rule. We know it's, it's going to, to not always get it right. It's perfectly okay to say, yeah, in that case, we just didn't get it right. I think what I proposed was maybe like some later thing if we can't solve it correctly or something like that. Yeah, telling, telling users they need to modify their freestyle job in order to get benefit from this feature is probably not quite as dramatic as telling them they need to upgrade the plugin, but it's, it's, it's, it's still rather dramatic thing. Oh, in order to use this, you have to upgrade the plugin, upgrade the plugin. That's fine. But oh, and you have to touch every one of your thousands of freestyle jobs. Hmm. Okay, so this is something I have to explore more now. And okay, after that, because I think these are the things I needed to discuss. I, we have three PRs, three open PRs, which Fran has reviewed the get to choose the test extensively. I, so I think it's if the other mentors can review it and then we could merge it. So of course, I'm going to push the new, the change in design, which where we just need one constructed. So I am going to make that push that in about after the meeting, I'll do it. So then I, in terms of get to choose it, it's complete. Sorry, I'm sorry. I just forgot the extensions. It wouldn't be complete. It would work for extensions with only get a brand source plugin and with public repositories, not even private repositories. That is how it is created right now. So if, if it's important for us, if it's critical for us to first implement it with private repositories as well, then this PR will be blocked till we figure out a way how to manage credentials and how to pass them. So that's a decision maintainers and the mentors can make. Then the other two PRs we have are later to the unsupported command feature that is checking if the extension is compatible with JGIT or not, and then recommending a feature and implementation. So I need to add test cases for the unsupported command class. I haven't, I've interactively tested it, not added the unit test cases. So yes, this is the gotten status. I have another maybe naive question and forgive, forgive all the questions that may have already come up in PRs. I'm sorry, I'm behind on the PRs also. But one question I have is, for public repositories, if you use API tokens too often, then I think that you get throttled. Will that have a negative effect on us? What is the API limit, right? The limit we have. So the BrandSource, GitHub BrandSource plugin I explored, they have a function that checks the API rate limit every time you're trying to make a request. So I think we can, we can just, we can add that function and just we can hope that request not being. So I, as far as I know, it's for a, for an unauthenticated user, it is 50 times in an hour. It's really low. It's low. So that would be a problem. Yes, yes, Mark. Go ahead. I shouldn't interrupt. Continue. I was just saying that I, at the time of doing it, I thought that, let me just think about figuring out, figuring it out for once. I don't, let's, we'll think, so I was thinking that we would, at some point of time, implement the authentication and that would remove the rate limit question. So yes, Justin, that's a very valid question and we cannot do anything about it. It would be a concern if we have a lot of projects which are trying to, actually it would be a big concern if we have a thousand freestyle job projects which are trying to, but then they would, would have to have the same repository URL as well in the same instance. I'm not sure how this would affect us. So if a particular, as far as I know, how would GitHub know that the same particular machines, it would map it with the IP, right? So for a particular machine's IP, that is how it knows that, okay, this particular IP is sending more than 50 requests in an hour. And then, I think so. Can't we just, can't we just rely on the branch source to manage the rate limit? It seems, it seems like the GitHub branch source at least has heroic and I, I do mean heroic. It's got two different choices. I can either choose to use a, what is it? I can use a linear barrier or I can declare that, that I don't want to block rate API, rate requests, API requests until I'm very near the threshold. And so they've got, they've got an awful lot of intelligence already inside the branch source, that branch source anyway. I would, I would just rely on them to do it. Now, it's a valid point though. I wonder, given, given the, given the relatively insensitive nature of our request for the size of a repository, should we consider a cache somewhere globally, which a little hash table, which remembers, we've already asked for the size of this repository, don't even bother asking again. Rishabh, is that already happening or every time a repository URL is referenced, you ask the question to the, to the, to the REST API provider? Every time we ask for it, we do not maintain a cache or do not maintain any kind of information. That may be something we might consider just because we know that the, the size of the repository is unlikely to decrease. And, and it's also unlikely to take dramatic increases in sizes in any given 24 hour period, right? And if it does, we made a poor choice that time and we'll get better next time. So, so, so something like a remember, remember, and if we asked in 24 hours, don't bother asking again, is not unreasonable. And it's a way of avoiding, you know, oh, we already asked, we've lived for a long time, we can, we don't have to ask again. That's, that's a great suggestion. I, okay. So, a table which maintains the sizes for a 24 hour. Yeah, something, the hash map, right? I mean, it's, it's not, this isn't, this isn't a big data structure, right? It's, we've got a repository URL and a, and a value. I think we may have just lost our job. I think we may have just lost him. Although we can still see his screen. Yeah, it looks like it looks like the power went out maybe. So, I was just navigating through the rate limit and I found one deprecation notice that GitHub will be discontinuing the password authentication from November. Well, so what, what they're discontinuing is the use of your password as a credential. But, but you shouldn't do that anyway. So, it's a good thing. Right. Yeah, they're completely shifting to the API one. Right. Hey, Rishabh's back. Okay, Rishabh. Yeah, I had a power cut. So, okay, so I was just saying that that's a great suggestion, Mark, and I would definitely implement that. So my question is, would we want that in this PR or can we have another PR for that? Later, yes. That's, you're welcome to go much later. That, that is, that is optimization after we've learned many more things. Yeah, and I think my concern is just like, I think you would just want to handle like, if the GitHub plug in branch source plugin thinks that it's going to hit a rate limit, maybe it should just say, like, I'm not going to give you the size or something like that, you know, something simple that would take care of and not make the performance worse. It's kind of like the idea. And maybe you've already considered that and that's already being handled. No, I just expected that it throws an exception. I will just say that, okay, we can, we cannot give you the size. That's what I have done, but that's a very valid point. And I would, so with the exception board, but yes, so authentication is what I'm going to do. We have to look and the last question I have is, so right now we have the get to choose as a PR, but we, I haven't, I haven't, I haven't put the instantiated the to choose all over the get to choose, get plug in wherever we are creating a client. So, so what I wanted to ask was, would we want different PRs for places where we're instantiating different places where instantiating the tool chooser so that we can focus on those areas specifically and not just in one PR we were everywhere we have the instance and maybe we missed some particular edge cases where the chooser would break cases or is that, is that okay? A PR, a single PR where we have all the places covered where the get tool chooser could be instantiated for the client. Ask, ask your question again. I'm sorry, Rishab, help me focus. It's not. So the question is that would we need different PRs for different places in the get plug in where we're going to instantiate get tool chooser or would it be comfortable for us to review it in just one PR? This for the current PR it doesn't instantiate the get to choose it anywhere it's just introducing the class within the plugin and the tests. I have put it one at one place so within the get SCM checkout create client. I haven't added the multi branch for multiple projects or add other places on the plugin. Am I audible to everyone? Just barely, you're a little garbled. So one PR or multiple PRs you get to choose. I don't know that I can see one being better than the other. It's we know we know we've got PRs to merge on get client plug in. We know we've got some to review still and merge on get plugin and it may let you work go forward in somewhat independently if you aren't inside those specific PRs but you get to choose. I hope sincerely to review the PRs this weekend. I apologize that I haven't still haven't done my due diligence. It's okay. So that's it from my side, I think. I'll be looking into authentication, how we're going to support the extensions, credentials and more discussion on the Gitter channel if I'm stuck somewhere. So thank you everyone for coming. Thanks Rishabh. Bye. Thanks. Bye.