 Welcome to Git Credentials Binding Google Summer of Code Project. It is the 7th of July, 8.30 am, India Standard Time. Mark, we started talking about what Harshad would have to do for his first evaluation and I was just telling him my experience. Because he was asking, does he require JavaDoc for his code and I told him that JavaDoc is something that is nice to have a feature for sustainability purposes. Yeah, but I was talking about my experience that what Harshad and I was saying that what Harshad would have to do is prepare a short demo along a company with a presentation which essentially would give his progress to the Jenkins community. So, I believe I'm not missing anything Mark. Oh, that's, that's correct. So, so what you'll, what you'll present is about a 15 minute, 15 minute minutes of slides and demonstration, and then five minutes of Q, question and answer. And that'll be during a CDF webinar. You should have received a request from Carla Della Mark. Have you have you received that request or do I need to remind her that she needs to send that out. Through the mail. Yes. No, I'm receiving request. Okay, interesting. Alright, so I'll, I'll so it will be the week at sea it will be the week after or the week of July 19. So what it is is, is the guidance was we've got, we've got the first evaluation begins July or can be submitted first evaluation submission by the mentors can begin July 12. It must be submitted be must be done by July 16. And we didn't want to, to make you do a presentation while we're in first in getting our first evaluation submission so we'll do it the week of July 19, and it's not sure if it will be Tuesday the 20th Wednesday the 21st. Usually it's one of those but she's she's working through that right now. And what you'll do is you'll present. There will be six projects presenting each a lot of 20 minutes with that 15 minutes presentation five minutes Q&A. And that that should definitely should include a demo. I'll share my present presentation I need for the first evaluation. I could share that presentation just for reference. Yeah, so did did that address the question on first evaluation phrase fades harsher. Yes. If I have any other doubt I will ask on the guitar chat or in the next meeting as well. Great. Okay, very good. Yeah, so in terms of changes in documentation. I think for the with credentials thing we've got. We have examples. And we have a pointer to the snippet generator so I'm not aware of anything else. It might be a nice to have not required. Two minute video or too many two minute screen cast two minute screen recording showing showing it showing the yeah. For instance it could show freestyle and could show pipeline, but that is absolutely not required. And I'd much rather you work on code than work on screen recordings because that's something I can do where others can do. I think the changes in documentation are done, at least in the get client plugin implementation we have currently. So you'd need to bring them over into the into the get plugin. So I'm going to change this to no changes required in documentation. Now we do need one of the things we need is we do need, need to review and merge the get client plugin API change right, and it would be best if we could release it as well. Now we can show you how to you can consume an incremental if we need to. Without much difficulty, we can show you how to do that. If for some reason there's something that causes say we're not ready to release that it's easy to to use an incremental as well. Let me get that PR number that was 700. That's this one. Good. Okay. Discuss if we if you want that shift from get client plugin and get client. Yes. I think that's this one right isn't that this this question, or do you want to do it as a separate topic. It was motivated by this question. So I think it should be okay. Sorry go on mark. I think I interrupted you. No, no, you go ahead. So at the time when I was investigating the get to resolution. Actually, her she raised a good point yesterday, which I actually failed to notice while I was doing the investigation that there is a principle difference between the context of the binding and what I was saying in the get plugin. So, at the get plugin level to get to resolution depends upon a name. And that is the user's choice or the default installation it could be anything but that there is a name which is passed to the resolution. And in her shit's case, what we have is the run context that is a context we have. And that's it right, we don't have anything else, except that we don't have the name of the get to so if we cannot. So I have not have not actually looked at the run. What what all it encompasses I've not checked that but her shit would we get the get to name by any chance from that object. Yes, we can get the get to name but there will be all the to get to names like it it was it will be an array of get to names it will be not a specific one that the user wants for the purpose. That's correct. So, so the run object does not have a an explicit SCM object or an array of SCM objects. I would have. So if it does get mark if it does contain a SCM object that means that the SCM object would have the associated get to Elizabeth. I would think so yeah but I haven't looked at it with a debugger to be sure so so the the run object. What's what's actually on it. I've, I'm not, I'm not immediately familiar with it. So, so the reason why I started that discussion that we should reconsider our choice of placing the binding at the client plugin was that I, the way I was seeing build information being passed in plugin and get client plugin did not have that kind of information to be there. That kind of was a hint that this sort of code should be placed within the plugin instead of the client which serves as a utility. But but then the very foundation of my assumptions are right now challenged by by what her ship pointed out yesterday that his get to resolution has not depend on the get to name. So, so that brings me to the question that is, is the binding as a binding, is it my responsibility to resolve a get to I actually, I think we need to. I'm not sure if that's that that's something that we need to do as a binding. So, what is the harm in choosing what we have the default installation. Okay, so, so have I have I understood your question, should the credentials binding except an optional get to name. Mark, if it does, who provides that information. The user, I would think, right. So, okay, as a parameter. So, isn't it. I mean, today, what they provide is, let's see, let me bring up the documentation. And today, the example shows with credentials, get username password and it takes a single argument today the credential ID. If it took an optional additional argument. Here, I'll just paste it like this. So today it does this. Right, oops. Okay, just as we do that in the SCM when we're creating a good SCM we do that. We ask for the get to name. Something like that is that I hadn't considered that but I think it's an interesting idea. When I'm building a get SCM, when I'm trying to check out the repository, at that point I do fill in that as a user I am expected to know the name of the tool I have chosen. Well, well you have the option of giving a get tool and if you don't give the get tool, it's assumed it will take default. It's assumed it will take the first in your in your selection. So, if if the global configuration lists command line get first it will choose that if the global configuration list j get first it will choose that. But was that was that answering your question. Yes, Mark, I just, I was, I wanted to ask that question because I was just thinking if the you should replace that responsibility to a user. But then since that that is already something that is an expectation from a user. It's optional. It doesn't, it's not a mandatory requirement but it's option but then we can extend the same thing in this binding context as well. Yeah. I'm harsher. What do you think would as you've as you've wrestled with the complications of resolving the get tool. If we would it make it better for you if it were an optional parameter from the user. Well, I thought of this actually yesterday, but I think that the user need not to. I just want to make things simple for the user. They are there. This is just like the, the, the credentials and the work is done. They don't have to do anything else. And that I want. And I think that that should be the default mode right I think we should absolutely make get tool entirely optional. So, if we were going to add get tool it should be optional I don't know that we need to add it. But if we were going to it should for sure be optional because we don't want them to think about it in the main case where they've only got command line get they say I'll take command line get whatever I've got. Yes, and her shit. So what you're saying means is I think there's a trade off. So either you can for for users and say convenience. You would have to iterate through all. I'm looking at a code and you would have to iterate through all the tools in an old and then you would have to find a particular get tool and then check if that get tool is applicable for that. And then provide that if it's an agent, if it's a controller, then you're, then you're looking for all the tool installations and find trying to find a good type of an installation. Right. Yeah, no, it's not ever traversing all the good tool it's just finding the first good tool of first tool of type good tool. In both of the cases. Yeah, in both the cases. It's similar to the good resolve. Well, the good resolve can traverse the whole list because it is name specific rather than type specific. So if the name is in the last, but yeah, the difference comes to the same like if the both the tools are in the larger tools are placed in the last. So they will have to traverse all the lists since it's, you know, it's a linear complexity. So the difference is same I think in the complexity case of both the implementations. The only problem I think that would have is that for each installation you're trying to find it's going to actually install it for which is the problem which I have seen. So I also had a same similar situation in get to choose it's a class I created last on my project, and I had to decide. I had to decide which which should we choose should we recommend and but I had the user's choice. So I was doing what resolved was doing. I am iterating through the get to list. So my question is that a chance so you think that we should not tell the user should not be concerned with it and we should be able to get it. But then let's say we have the binding and in a pipeline. And the risk of doing this twice. Because at the SCM level resolve get to will try to find a tool and then they're going to do the same thing after that. I don't think so we have a risk of running it twice. Well it first of it will figure out where the agent is running if it's running on the it's no type, then it will run the no type code if it's a controller type then it will run the controller type code. So, the question is that since the, as you also also said, we have similar implementation and resolve it to write. So, resolve get to is going to work. When the SCM is going to be a. During the initial processes of a pipeline, and your binding is going to be placed after that for for a case and I'm just I'm just giving you a case where the first the tool is going to be resolved by get to resolve get to buyer because because the get SCM and then it comes to your code and then it again goes for the same resolution. So we're doing the same won't be doing the same thing twice. The resolution. You may have a different way of doing it the resolution has a different way of doing it but essentially both of them, how do they validate if a note contains the right get to install it. That's how they validate it right. That is the cost of validating the right. The search is linear but installation is what the time. We have to consider and it's a trade off. I am not saying that we cannot do that. I'm just thinking out loud. Is it is it a trade. Do we want users can be used. No, I think. I think we should have a point. So, so the example that I have in my mind is. So if in a freestyle job, we are performing a good checkout so it will use the good resolve tool to find the tool. Get a good to write and after that when we are performing the using up my binding in the batch script. So we are performing again that thing but using a type specific implementation of the same. Is that right? Yeah, and also in a multi plans project as well. So yeah, I think we should have a good point. I think we don't want users convenience. We will work. We want the less. You know less computation time. Yeah, that's the next question is that how do you share that information. Let's say we don't want. I will I think we will need from the user only because the bindings context is independent. Actually, I don't I have I don't have an answer. I don't know I have never. The context which is presented to the binding. Does it contain. What is that like, like, as Mark mentioned, that if it contains the SCM objects, then that means that it would have ticket SCM object which is executed. I'm actually, I don't know just at this point I'm guessing. Maybe that's an exploration. So what is our timeline right now. We have a revolution. So, Mark, what is the what was the plan for our release for this future. So, good question. So the release plan that we had originally discussed was deliver username password during phase one. So let's say release during phase one, and then release SSH during phase two. But, but again, I'm okay if we say now we've decided against that there's we need to do some more work. For me, I've, for instance, I'm not ready to release the current username password because freestyle projects still don't work for me. I don't know. Don't work for Mark and I haven't had the time yet to, to understand why because they do work for for hardship pipeline projects work great. We have a unit test. Yes, yes, we do actually at least for, I think we have an automated test case for freestyle. We don't have a pipeline automated tests but we know how to write one. There are pipeline automated tests that would illustrate it in the get plugin. So we, and I can't explain why it fails in my in my installation but works in the automated test. I think we have some time to explore that explore the options so the user's option is, I think, like what is the most plausible direction we could take. I just want to also see if the context which is provided to the binding is something which we can use to get it because user has already chosen to get to once. Can you use that information if, if not then I think the clear approaches to ask the user and then I think it becomes easier for you right. If you're working in the get plugin environment you just have to use the in both the gate is all default, default installation right. Yeah. So Rishabh did I capture what you were describing correctly there. Okay. So harsh. Oh, go ahead. What was your question harsh it. So if I mean I'm just hypothetically making an assumption. So, if there is no SM object in the instance, then, then there will be get to name run twice resolve sorry it resolve to name will be run twice. I think so. Yes. So, I think that comes to the same scenario. We were not using the not taking the input from the user. Yeah, and, and I would guess resolving twice is still much cheap much cheaper time wise than any get command line get operation. Right, even to the local disk because resolving yes resolving get tool is just Java code in memory, whereas as soon as we call command line get we're forking a process and talking to disk drives and so I'm not. I'm actually not overly worried if we end up resolving the get tool twice that I the performance impact will be below our ability to detect it. Now, if, if, if it does do an unpack, and there are many tools to find that would be different right and Richard, I think that was what you were saying is that the resolve get tool when we when we were working with it last year we have a scenario where we were actually installing the tool multiple times in order to resolve it. The problem was that I was, I was fetching all the get tools, and then I was resolving each of them one by one to see which one is applicable for my case and I think at that point it was unpacking the installations and installing them. Okay. Do you mean that the get the binding is where you placed in the get plugin. All of this is being done under that assumption. I think so, could you say that again I'm not sure I heard everything I think you said something about binding assumed to be happening inside the context of the get plugin. I was saying that are we then shifting the code for the binding to the get plugin. That was, that was my assumption and harsh it. Have you found something which would say no we should not switch the implementation into the get plugin. Not yet. Okay. And have you have you actually started that move or is it is it still pending. Very good okay great so we should we will probably then know very soon if that's if you hit some unexpected terrible problem that tells us oh that's not going to work. Also I was thinking so, if we have a choice of taking input from the user, then why not take the the get version name version input from the user as well. Why are we using the command line get. I mean the command line option. Oh, good question right okay so. And I had assumed that we didn't want to depend on the user knowing what the version was of the of command line get, but it's a you've got a good point. So, so if we, if we, if we accept an optional get tool parameter. Should we also accept an optional get version parameter, rather than asking command line get for its version. Is that what you're asking. Yeah, and so for me it was just a matter of convenience for the user so that they could call the thing get and not have to worry which version it is. And if, as an example when that would be a bad problem. Mark's installation has the default tool. And on CentOS seven. It is get 1.8 on Ubuntu on Debian 10. It is get 2.7 I think on my Ubuntu 18 with custom installation it's get 2.32 on Windows it's get 2.32 and so. In that case, I get version I wouldn't know how to answer the answer that value. Because the same job could execute on any one of these, and I don't know which one of them it's going to execute on. Oh, yes. If you choose the agent type 20 in the pipeline. Right, if I said agent any or if I said agent Linux, Linux has this wide variation right or if I said Linux or free BSD or Linux or free BSD or open BSD any of those. So I'm prone to say don't we wouldn't take CLI we wouldn't, we would not want to stop asking CLI get for its version because that question has to be done on the agent where we're doing the work. Any, any other questions harsher. See, have you ever used incrementals harsher in in a Jenkins plugin. I assume not. No. Okay, so, see, let me get include a link here so that you know how to do that so that you're, you're not blocked waiting for a release of the get client plugin. Let me find that Jenkins use incrementals. Incremental in development. Incrementals developing components in parallel. Here we go. See incrementals. Developing components in parallel instructions to develop to use the get client API the new get client API before get client plugin is actually released. Here link will help you. The page looks like this. Developing components in parallel creating a pull request obtaining the version number, etc. And then, instead of Jenkins that version you would put that version in the get client section of the, the get client dependency inside the get plugins palm dot XML, there may actually be something about how to do it with plugins. Like just that one. And, and I think the, the get client API is simple addition is simple. We can release it quickly. So I don't think that we don't need to let that be a barrier for you. Anything else. No, no, no, no. Okay, and harsh it, given where you're at in terms of implementation, I'm assuming we probably want to meet again on Friday to be sure that we talk is that good okay so plan to meet again on Friday. Review progress. Prepare for for end of phase one, prepare to complete phase one. And just as a word of warning, Mark's grandchildren will be visiting that day. It may be noisy. I have shared the presentation. Thanks Rishabh. Thanks very much. Anything else we should review before we close for today. So, for the SSH binding, I have. So, I have created the. So it's working for keys with which are not in open SSH format, and which are not in which are encrypted by passwords. Oh, very good. But you so and using a passphrase. Yeah, both. With a fast phrase or without a fast phrase. That's great. Also, I am working on the SSHJ library to create the implementation for open SSH format key. With pass and without pass. Well, I have created it, but I am getting a few errors, but I think they will be resolved in a few days. Very good. And you're fine with using the SSJ library because I remember you have a question on the chat. Yeah, I'm good with that. I just wanted to, I mean, I wanted the Bouncy Castle API plugin of Jenkins to have open SSH key implementation as well. I mean, it only has implementation for PEM formatted keys or keys which are in P other formats. One was P, C, K, S, eight, something like that. I think since the open SSH format is pretty new and should be implemented. But currently Bouncy Castle, the team themselves have admitted that they don't support passphrase directed open SSH private key. Right. Yeah, I mean, no, I'm saying Bouncy Castle API plugin for Jenkins. That support in that. What you want to do is you want to do the same thing which SSJ library is doing because I assume that they also have a custom implementation built upon the Bouncy Castle API. No, they have not using the Bouncy Castle API. They have created their own implementation from the scratch, I think so. Bouncy Castle API, the class they use the Bouncy Castle API have a limited scope. So they don't have to use that they have created their own implementation from scratch from what I have seen. I think I was under the wrong impression that they have modified the implementation. No, no, no. So what you're saying is that you want to do the same thing for the Bouncy Castle API plugin. Yeah. In Jenkins. I'm not sure I understand that so you're the Bouncy Castle API plugin is just a copy of the Bouncy Castle API published as a Jenkins plugin. Are you suggesting you're going to extend the Bouncy Castle API in some way that's not using some portion of Bouncy Castle. Yeah. I'm planning to submit a I would expect them to reject that so let me say what I think I heard so proposing to add a non bouncy castle API to the Bouncy Castle API plugin. Yeah, to support openness as format. Okay, but and I would expect them to just say say no, because what they will say is now just create a new plugin create a different plugin that provides that new API. Oh, yeah. Because because the one of the things these API plugins do is they just present the API of the plugin at least as far as I understand it. But you could certainly check with the maintainers of the bouncy castle API plugin just to be sure. But I would assume just inside inside the get plug and just depend directly on the SSHJ library. The SSH implementation for in our case will depend on the SSJ library. It will. Okay. So that I'm not sure I'm understanding. Oh, go ahead. It's just something I'm thinking of after I have completed the shock. I see. Okay. All right. So, so then what you might do is, hey, offer a pull request all the way to the upstream bouncy castle API saying hey, here's support for open SSH format. Because because that certainly is also very valuable. If we've got time available and you could submit to them all the better. I wouldn't attempt to put it inside the bouncy castle API plugin. I would rather just ask them to include it in bouncy castle itself if you've got, if it turns out we have capacity for you to write that code that would be great. It would be really cool for a Google summer of code project to submit something to bouncy castle. Anything else. Oh, go ahead. No, nothing. That's all for today. I'm going to shut up anything else from you. Right. Thanks everybody. I'll end the call and upload the recording probably in the next 30 minutes or so.