 Welcome, everyone. It's Git Credentials Binding Project. This is the, oops, 14th of July. It's 7.30 AM India Standard Time. So topics we see. I should have some questions. I can describe some of the results of my interactive testing. And then code review results and open questions. Any other topics? Okay, then let's go ahead. Let's get started. So, you had the question about which OS environments has the Git user name password binding been tested on. So the controller has been tested on Linux running in a Docker container. It's easy for me to test. Easy to add Linux running on Debian 10. If that will help. I have one of those it runs and I'll I'll be putting it there very soon anyway I just haven't done it yet. Then in terms of agents. It's been tested on Centos seven Centos eight. Debian nine Debian 10 Debian testing, which is a pre release of Debian 11. It's been tested on Ubuntu 18.04 Ubuntu 20.04 Ubuntu 21. I don't remember if that's 04 or 21 something or other but one definitely 21. It's been tested on open BSD 6.9 free BSD 12.2. So that's, let's talk about those agent operating systems. Then if we talk about agent hardware. It's been tested on AMD 64 arm 64 system 390 mainframe. This is an IBM mainframe class piece of equipment. And I think I don't think I've yet test on power PC 64 le. Oh, it's also been tests on arm 32. So 32 bit arm on a Raspberry Pi. These are 64 bit arm. AWS and Oracle cloud. So does that answer your question. Harsh it in terms of where we've been run and where tests have run. Yeah. Any concerns there any any worry about. Oh hey what are we missing. See I should probably double check I may have understated something there just a minute. Let's do one more check. So if we look at the agent. So we mentioned free BS. Oh windows. I didn't mention windows. Oops. Sorry. Windows 10. And now. So. Yeah, arm 64. Free BS D 12. Center seven, eight, 10, nine. 18 20 and 21. Free BS D windows. S 390. I think it's offline right now because it had a DNS resolution problem that I need to check. Windows. That is going to 18 on arm. These are arm 64 Oracle Linux, right. Oops, shame on me. Missed another one. Okay. Sorry. Oracle Linux. Eight. That's eight dot four. Oh open Susie. Right. Sorry. One more. And I think that's 15. Two, but let's double check just a minute. Okay. Yeah. So does, does that, does that address. Were there specific concerns you had? Or worries. One of the, so maybe we should highlight a different, a different question, which is. Which OS environments. Have not been deeply tested. Well tested. And, and the one that is most of concern to me is controller. Windows. Right. Because there are things that happen only on the controller. And I haven't done an awful. I haven't done. Any testing of. The code running on a windows controller. Now I believe. Yeah. Go ahead. Windows controller. I mean. I've tested the binding mostly on the windows controller. So I think it's. Okay. From my side. Great. Okay. One of the concerns for, well, yeah. So very good. Excellent. Okay. How should you have a concern with the SE Linux, right? Security. And send us distribution. Yeah. Send to a son, but Mark says if it's running well on a center seven, then I guess. But the SEL links might not be an issue with the binding. Well, the, I would, I would phrase it differently. SE Linux is an interesting, interesting concept because what that is, is that's. Sentos. Red, let's call it red hat. Or Oracle Linux. Configured with SE. Linux. And the answer there is. It's known to not. The plugin itself is known to not run well. On SE Linux. So there isn't much. There isn't much that I can, we can offer there. We've got. We've got an open. We've got a. One or two pull requests from. Major Jenkins contributor. But. Dev work in progress. To improve the plugin. On SE Linux, but it's, it's very much in progress. And I don't actually intend to install or configure SE Linux because I don't have use for it. And I don't know. Well, I know that in the last 15 years, there haven't been that many users using it because if there had been, there would have been an awful lot of complaining. So for me, I'd propose we intentionally, we accept. That this needs to be tested. By those who use SE Linux. Because I. I am not a credible. Tester of it. I would not know. I would not know how to detect pass or fail of many things. So, um, so do you propose that we. We release it and then see if. Yes. Yeah. So for instance, I can give you other examples of things where places where we haven't run it. We haven't run on it, run it on and. Let's see. So we haven't run it on. A. On power PC or on. HPEs HPEs. What do they call it? Fault resilient Linux and I forget the name of it or fault resilient. Unix clone. How embarrassing. What is the name of that operating system. Nonstop. There we go. I knew I would remember it. Okay. So, I don't know. There's no links to Google HPs nonstop. I know we've got a user. One, at least one user. Randall Beck or who works on that kind of equipment. But. I have no access to it. And. There are others like that where. Hey, if we don't have access. We can't test it. Can we safely assume that. Hardware is not going to create an issue. I think even if we couldn't safely assume it, we have to assume it because without access to the hardware, there's no way to test it. As far as I've seen, I had never tested these HPE nonstop servers and had not tested PowerPC until 18 months ago, but had never tested nonstop. And it works just great for Randall. So Java is surprisingly portable across platforms without us doing a lot of work. So, Harsh, any other concerns there or worries that we need to be sure we address? No, I don't think of any now, but I'm fine for now, I guess. OK. Yeah, my concern was we'll talk about mine in test results. Mine was not so much with platforms or operating systems. Those are working great. It's cases where users may make a configuration mistake and the configuration mistake causes the code to not behave well and not necessarily to give a warning message to tell them what mistake they made. But we'll get there. So after next question, there was after where do we put the documentation, right? So here's let's look at the current documentation. I was assuming it would go in the section under pipelines and talk about pipelines and then another section probably, I would guess, right after pipelines is a top level section preceding configuration that says using credentials binding. Now, and you were thinking after the configuration section, that would be fine as well, probably even better. So instead of putting it there, Harsh, your thinking was put it right before this extension section. And that would be just great as well. For me, I wanted it in the pipeline section in addition just because I think that it's a great addition to pipelines. I know it's more than pipelines. You can also use it with freestyle. And I've confirmed it works great with freestyle. But I like it with pipelines because we talk about pipelines in the documentation. We talk about multi-branch. And then we add one more section here on using advanced get functionality with our get credentials binding for advanced functionality in pipelines. And then we give some good examples there of, hey, maybe you want to do sub-module update, or maybe you need to do this special type of clone or you need to do this additional thing and you need to apply a tag and push it. Here's how you do it. So, Harsh, what do you think? Does that make sense to you or what would you prefer? OK, that is also fine. But we have to explain a bit about what is credentials binding in the pipeline section also. Yes, right. Well, and actually, I just, maybe we should, let's take a look for just a minute, because these common tasks, I just closed several bug reports, specifically saying, we're not going to fix this request because credentials binding will do a better job of it anyway. Just a minute, let me see if I can find those. Status enclosed, updated here. Ah, yes. OK, good. So here are some examples. So Jenkins 38.860 asks for, hey, the get plugin is doing strange things with sub-modules. And that is absolutely the truth. It is. It does. What it does with sub-modules, I think, is flawed and a mistake. Doesn't handle sub-modules with spaces in it. Somebody else asked for, hey, I'd like to have the ability to clone with the shallow sense option. Yep, agreed. That's a great idea. I'd like to use first parent in the get log command. Yep, those are all great choices. And so each of those, I think, are good excuses to put in the documentation saying, hey, use these things. See Jenkins 38.072 for an example. Oh, no, no, 38.860. Harsha could also potentially use these tickets as a user's motivation to release this feature by at least presenting this idea. Oh, yes, yes. Oh, that would be a great, in fact, great thing to put in the slides saying, hey, here's some of the reasons why we did this feature instead of, here is a list of five other things. The amount of flexibility it provides to the get plugin. I think it's a clear example of that. Yeah, very good. Because it absolutely is. And it's done a very nice reduction of the debt that we have in the get plugin where people say, I need this particularly complicated thing. And the answer is we're not going to add that because it's just too narrow for the large base of users that there are for the get plugin. OK, creating and pushing a tag. OK, so is that sufficient there, Harsha, in terms of what should be next there for documentation? Yeah, yeah. Yeah. All right. So next was the GSOC meetup. And where to submit the slides or recorded demos, send them to Cara de la Marc. And she'll include in the materials. Should I reply to the mail that I received, or should I send a separate email? Reply to the email that way. And actually, if you'll do a group, a reply all, that will encourage other people to do the same thing. Because right now, I'm a little worried that people are not replying nearly enough. And Cara very much needs that to happen. This presentation will be next week, and we're going to start promoting it very actively this week. And any other questions on that topic? No, not that one. Yeah, a little bit. I just want to know, in the final week of the GSOC, there will be another GSOC meetup by Jenkins? Or is this the first and the last? So we've in the past consistently had two presentations, or we've had presentations, so consistently, had presentations in the middle, and at the end. So does that answer your question, or were you thinking, will there be two more presentations? No, it answers my question. OK, and then DevOps World, another presentation, and that one is what's called the lightning talk. And there it's, I believe it's five to 10 minutes. I think it's 10 minutes. Rishabh, do you remember was it 10 minutes? Yeah, the lightning talk, no, it was five minutes. Yeah, so let's see the request from Alyssa Tong. Didn't we just have the DevOps World recently? No. So it'll be September 21, September. And I think I don't remember the exact date, but it'll be in the month of September. Plenty of opportunities to discuss the project. Right, right, you should get used to presenting actually, Harshik, because you're going to be doing several presentations. And that's part of the, actually part of the skill development here, and it's a great thing. You're presenting to large groups of people who are very interested in your work. Yeah, it's a great opportunity. OK, so anything else there? Well, yeah, I have one little doubt. I asked in the previous meeting as well regarding the test case for with authentication commands. Do we have to write a test case for with authentication commands? Oh, good question. OK, so let's take that as a separate test cases, tests. Do we need an automated test of authenticated operations? Right, current automation checks the variables and the user set does not check end-to-end operation, right? Yeah. And my sense is Mark's preference for now is no, because we've done good interactive testing. And the infrastructure to maintain automated tests of authenticated operations is expensive and is brittle and expensive. And when I say expensive, I just mean it tends to break. It tends to waste time as we try to maintain it and it doesn't tell us all the things that interactive testing tells us. So we continue to rely on periodic interactive testing. Now that may be an uncomfortable thing to say, but I've got a significant interactive test setup that I'm using now and it will continue to be used and run and checked on new releases of the plugin. Now, Harsh, that doesn't stop us eventually from doing this, but I would much rather we shift and have you able to focus on the SSH work on the private key work than worry about adding these authenticated operation tests. Well, I made few commits yesterday that were regarding the automated tests and the coverage report is 90% plus. Excellent. Well, and I loved, I love the additions you made. Additions added for declarative, if I remember right, declarative pipeline, and possibly also for scripted. I know I saw at least one test and possibly two that was included in the automated tests for pipeline. So that was brilliant. Thank you very much. All right, so anything else on automated tests? Okay. All right, so I had wanted to talk through some of the things I'd seen in my interactive testing. I think I've made notes on them in inside the poll request. Let's go there and take a look at it. Oh, maybe I didn't. This transient is resolved. Okay, I must not have, I must not have made my notes. Sorry about that. So let me give an overview of what I've got. And here are the tests that. So what I, what I started with was a series of tests to check several different providers. So GitHub, get lab, bit bucket. And those three providers I've checked on windows. Both PowerShell and batch files. And with pipelines. So here's a pipeline test. And it's well, well behaved. It's just doing a. Get poll. If I remember right inside the. Here we go. Yeah, so it does. It does nothing outside of with credentials and performs the entire clone, poll, etc. Inside and it's working. Likewise forget lab. Oh, bit buckets failing. Why is bit bucket failing. Oh, right. Huh. Okay. This is a fun one. It's failing on the S390 agent because it can't resolve a host name. And I checked and there's something wrong with the host name resolution on that, on that machine. So let's build it now. It will skip S390. There we go. This time it built. Oh, no, it built on S390 and it's been fixed. Great. So mainframe works. This one was on Windows. Using the with credentials. This one on Windows using a batch file. So this one was using PowerShell. This one uses a batch. So that part felt really good. And then. Then I've also got a bunch of test cases. That are run in different environments. Using a. A pipeline. So here's a pipeline definition with. Okay, here's a freestyle job using it. Another freestyle job using a batch file and then. Now here is a. Parameterized pipeline with the credentials binding. Parameterized all of them I've checked recently are working. And that one has shown a failure where. Oh, again, system 390 that's built now. So, so good coverage. Now what one of the gaps for me was I was allowed to provide. A credential ID without a git tool name. And the job fails consistently. So I'm going to go to the pipeline. Arguments. Named arguments are usually considered. Are typically. Considered optional, I think. Now I may be wrong on that one. So. That one surprised me. And then I was allowed to provide. Provide a non existing. Get tool name. And I was allowed to provide a. Oh, right. And then the freestyle job. Get tool name. And the syntax generator. Use a text field rather than drop down list. And that was, that was a surprise for me. I was expecting a drop down list to make sure I would choose one of the known. Valid get tools. Any, any questions there or. I think, I think even with those limitations. We'd still be ready to ready to deliver ready to ship it. And just warn people that, hey, you need to provide a valid get tool name. And if not. You've got to. The job may fail. Which I did not. So I did not imagine that they were going to. Trade off. Potentially. So we will lose some people. We failed some jobs where people. Are not aware where the users are not aware of the. And earlier when we were. Resolving the get tool ourselves or at least trying to do that. We. Those cases would have worked. Let's say I don't know the. Name. And internally it results to be the default installation that. Be a valid. Use case, but in this case. When we've made the. Argument mandate. Then it. It blocks those users. They're not. Correct. So, so if we. If we look at the pipeline syntax generator, let's, let's go there and we can look at that to see. How it, how it feels to the user. So the user does with credentials. They select get user name and password. They enter some value here and I still can't explain why this doesn't show any of my credentials. And there is the get tool name default and they pick generate. And this is valid syntax and absolutely will work for them. Now, if they put in here. No, no text. Or if they put in here. Not a valid get tool. It will generate that, but when they use that it will fail. Even if they put in a valid credentials ID. This not a valid get tool will cause the job to fail. Rather than falling back and using the default. And I don't know in that case if we should fall back and use the default. But, and there isn't a way from the syntax generator any longer to generate something that does not have a get tool name value, even if it's the empty string. So then my question is that why not fail. Even if the user is giving us a long choice. What is the harm in provide in trying to attempt to use the default installation. If it's going to fail, it's going to fail. But at least if the user and let's say by mistake or without the required context. Added the wrong. And if the default installation fails, those cases we would, we would still achieve a better. I would say broader. We would maybe. Not based those cases. Question. What's your experience been there? Did you get to hear the question? Yeah, sorry. I didn't see that. So. Yeah, I heard the issues question and I was saying the. Later to the resolve it too. It's like it has nothing to do with the code I have developed. So if we provide an empty. An empty input or empty string. The it's the. The responsibility of the resolve it to method to check it. I mean. I'm just writing the name. Everything has to be handled by the resolve it to. Before we were using that. That was my code that was using. I mean. I mean. I mean. I mean. I mean. I mean. I think that was the best example of using them there. That was my code that was using. That was, you know. Taking responsibility of finding an appropriate tool. So, so, but, but even so doesn't. When, when, when you call resolve git tool, it's giving back a response, right? And that response. I assume if it's. Whoops. Here we've got the call to resolve get tool. It's a blank or I think it will give us the default installation. Oh, you're thinking it that this call will resolve to something. And yet I'm definitely seeing cases where well let's let me double check but I'm pretty sure that if I modify a pipeline definition. Let's replay this pipeline. So here we've got the with credentials call. And if I remove this get tool name. Or let's make it non existent tool. And when I my recollection is when I run this. It will fail. Yeah, there it is. Fatal could not read username so. I'm sorry I actually miss that what did you put for the game. For the get to name here let's look at it shows I put in the get tool name. Okay, non existent tool so there's there's one so now let's try it with. Assume that was was calling into where to go calling into the source code here, and that this was likely returning null. And then that was causing this to return null. But I don't know for sure I haven't run it in a debugger to be sure and I ended to confirm that. I think that would be the. Yeah, I think that it should return default get tools for the controller or the agent they are running on. Okay. Yeah, it should never turn null actually. But how should if if the if the get to name is something which does not exist. Then it's going to solve it as a man. So it is there's a case that handles that which falls back to default implementation. Mark, if you could open the resolve implementation that. Sure, you bet. Okay, so here is get you tools. Okay, and here is the resolve get tool implementation. So in the if the first condition if it is equal equal to null. Well, but but the tool that I passed in is non null, right so I definitely passed in a non null so it will, it will try to find one with my non existing name and that would be null. And then it does a get of the default installation. Okay, so, so it should have returned the default installation. Interesting. Okay, so I think this is a mark needs to investigate further because that surprises me I would have expected. Mark check. Why. No, why an invalid get tool is not using the default, or if it is why it's not working. Mark, you can see the build messages if there's a message saying select grid installation doesn't exist using default. Oh yes good check right we should be able to see that shouldn't we. Very good so let's look at the console output. There is yes. But then it says Jake and Jake it. Okay, and I don't understand that second message there. It means the good tool that. Okay, so it means that the good tool is not off type. Good, or you can say it's off type get jgit or jgit Apache so that's why it's not working. But but that is surprising right because the invalid tool type that I gave was certainly not jgit and not jgit Apache it was. Something that's none of the above. Yeah, but the default in installation of the good tool that your controller the agent you're running on have is off type jgit and jgit Apache. So that's why. Okay, and now that part surprises me so that's where what you're saying is because I thought was wrong one global tool configuration just a minute. I think I have the first preference is get not jgit. In fact, jgit and jgit Apache are the very last in my list. But what what you're saying is it's choosing oops it is choosing jgit where to go someplace around here. For whatever reason here it is choosing jgit or or or thinks that the invalid thing I did is a jgit or a jgit Apache. But then why would it do so if it's using the default installation with that environment where the installations have the CLI to install. Yeah. Okay, so understand why when. Okay, so why that message when an invalid tool is selected invalid tool name is given. Good. Okay, at least I understand what I need to investigate. Great. Okay. I think at least I we've got an open item here to investigate but I don't think seems to default to return a jgit or jgit Apache tool type, rather than a CLI tool type. So that's a little surprising but but that may just be that I know that there were some odd behaviors in the get plug in where it was defaulting to return jgit. So that may be the same thing needs more investigation but I don't think that blocks us from shipping the code. Harsh it are you are Mishab are you okay with how it's been described so far and we'll do more investigation to understand it. Yes, 100% mark I think my concern that a user providing providing a wrong name. I think it's a dress because we would return back the default installation in that case that is all good. So I should is right that we will cover that case. Okay. Yeah, good. Alright, so we've got this one to investigate still great. Okay. Next, anything else on that topic before we touch this next one. I just have a small question if we have the time. I just want to ask that how should you're trying to check if if the if the installation type equals get to the class or not. Yeah. And you're doing that to why are you doing that. Are we not is that not guaranteed by the result get to. Okay. So I need to look at the code. So I just want to ask them why why what is the reason for placing this check. This install that only get specific on you can say I see like it specific good tool goes to the to the binding and performs the operation and any other type like J. Apache does not as far as I I know the gift tool is is the class which is implemented by the other tools right. Yeah. Okay. No, you're right. Extends get to. Yeah. Then how are we Mark, I guess, I mean, no, that's fine. No, there's a line saying see in that type specific tool. So here on line 38 we are ensuring that the class is there, it really did get installation reveals its class. So using this to get installation. And yeah, my question is that if we're checking if it's off type get tool and J get tool and J get Apache to extend it. And what are we going to get the line third line the yeah the code on the line 38 is with this case only. So it will. So if we Sorry. If we look at the get tool name specific to object then the and we look at the class it will show us get tool dot class but if we perform this the code on line 38 and search for the good tool with the name specific with the name specified. Then the class is revealed. So it will tell us which class it the good tool is from it is from J get a tool or J get Apache or it is from good tool. So after revealing the class then I'm performing the check. Probably. And just look more into the. I understand what you're saying. Or should I just need to look at the phone. Yeah, so I think I think your question is there. Right. And so let's let's capture that just to be sure right so do we need a check for exact class match in that I mean yeah we do need that because if we look at the way and we are setting the if we are checking the version of the get then we have to ensure that the get implementation is CLI get and not J get or J get Apache. And we have to by checking for get tool dot class that tells us it's CLI get not J get or J get Apache. That's surprising. But but actually this is a great one for us to just we can we can use a debugger because this code I believe is executed inside the automated tests and the automated tests. Pass in J get pass in J get Apache and CLI get so we can just watch it execute. So that's that's something that's pretty easy to check with a debugger to see okay is is this condition ever falls. And I've created a separate test case also for this thing to check this this method gets CLI get to where you can check that. Yeah, I do that I like to read the whole thing. Okay, so the separate test was should be okay so we've got here basic setup this one. No that just clears the tool instance okay then freestyle pipeline. There we go is this the test you're referencing. Yes. Good so we've we've got automated test cases we can use to check it. Excellent. Okay. I'm, we've, we've hit our hour. I've, I wanted to double check on one more topic could both of you spend another five minutes on on this before we end. Okay, there was one code review open question it was related to the get client plugin choice of the API name in the in the proposed change here so the proposal was, let's add a new method is CLI get ver at least. And a question and it's got tests very very good. The question from me and then also from, I think, Justin and Rishabh had the same question. Why not just expose the existing method make it public. Any insights you want to offer their harsh it. I just dwell the rapper method for that. I mean, I could create it public. I just want to get a rapper method for that purpose only. My concern was this, not a concern this in observation that if we're exposing it via a rapper then essentially it renders that protection package protection. It is public, because we're not doing, we're not placing any additional check or any logic which is essentially one thing that one thing that I was a bit concerned was in the future, if we need any implementation change then we could use this method instead of making everything in that in the least version. So we have the rapper method and we could modify it according to our need, or we can create another one as well but That's a great, I think that's a great point. So you're saying that this could be used particularly for the logic of the get binding. Yeah, for now it is being used for the get binding only but in the future we don't know where it might be used. Right, good. I have no objections at all to just going with this as it is and delivering a version of the client plugin that includes this. So, so for me I think I'm okay with that. Yeah, it's the same for me. Great. Okay, so I'm going to go ahead and, and I think I'm going to add these closing punctuation into it. Just that way I don't have to deal with risks from Java doc complaining about sentences that aren't ended. Java doc is a little bit finicky so still approved. And now I'm going to go ahead and take advantage of I think you've still allowed me permission to commit to this one. Add to the batch add to the batch. Alright, the suggestions. Add punctuation. Java doc. And then when this completes, I think we're ready to go ahead and release this. I'll actually increment the version number harsh it just for your info. I believe to three dot eight dot zero. Just because it's adding a new API and that way this is a way to declare that it's a formatting shame on me. Okay, good. Alright, that was the API name in get client plug in question resolved. Great. That was what I needed. So next steps then mark to merge. Merge and release of and release get client. And then a harsh it you will update the poll request to use the new release. And then we're I think we're ready to review one more time. Prepare to release any objections to a release of username and password. Because I've still got questions in the debugger that I need to, I want to be sure I understand that. It's the same for me. It's around the victim resolution and I just have to check. I think that's my investigation. All right, harsh it thanks very much now we're scheduled I think our next session is is scheduled for later this week right. Right. Great. Thanks everybody. I'll make the recording available later. Any other topics before we end for the day. No, I don't have a topic but I just want to know mark how you are running agents on your Jenkins instance we are using SSH for that. I use a wide range of choices so here I can talk to you about that as well so for example. This agent uses SSH. This agent uses inbound, not SSH so it uses an inbound connection. This agent uses what's called the Jenkins swarm as a technique of connecting and most of the other agents use SSH. So I have a wide variety of connection to I have an intentional variety of connection types. I am not using any Kubernetes and I'm not using any Web socket at this point so there are still some connection types that I'm not testing here but I've I'm intentionally testing a variation of different connection types to be sure that they're all well behaved. Good question. Very good. I'm glad you glad somebody else thinks about how are those agents connected and could they be doing something different in one connection than another. Well done. All right. Anything else. Thanks everybody. Talk to you on Friday.