 Welcome to Git Plugin, the Git credentials binding Google Summer of Code project for Jenkins. This is office hours and mentoring. So remember, we abide by the Google Summer, the Jenkins project code of conduct. It's the 25th of May. Harsh, do you have questions that you wanted to open with or any progress you wanted to share? Should I share the demo that I showed, I mean shared in the Twitter chat? That would be great if you're willing. That would be wonderful because then we have the benefit of a recording of it that we can point others to. And I'm sorry, I'm interrupting. I just wanted to say that Mark, we usually share our screen with the doc we have, right? So that we have a context of what we're going to talk about. Right. And I didn't do that. Let me get that doc ready. Well, Harsh, if you can start sharing your screen and I'll get the doc ready to be sure we've got a copy of the note. It's visible like this. Yes, I should. Yes, looks great. Yeah. So I created the demo one, this is the pipeline job and first I would like to discuss the script. So yeah, like I shared about that concern I told you on the chat about the SH command. So instead of using the clone, I used it step to clone and fetch so that the user don't get any error. And also I would like, like the repository I'm cloning. Is this a private repo, Harsh, because I was able, I was trying to access this. Okay. Yeah, this is a private. I'm not signed in this PC, but I can show you in this one for one second. Yeah. And, and private repo is a perfect check. So that's an excellent choice. Yeah, definitely. Nice. So this is a private repo. See, I'm working on this. So I will be pushing my changes to this repo. The font is visible. Or it's too small. That's okay for me. Anyone else see. Yeah, very readable. Okay. So in this step, I am adding the. First removing the tags, because if the tag already exists, it shows an error. So I have to first remove the tag. If it already exists, then I have to add. And then I will clone any changes or fetch them. Then I will push the, push, push the changes or you can say push the tag in the repo and then I'm creating us like a temporary file so that you know that it's working. And then I'm pushing all the changes. So let me start it. Oh, they already exist. That already shows that that message fatal tag already exists. Oh, let's see. No, that's on the get tag operation. Okay. So I mean, you could, you could randomize that tag or put a. Yeah, they're, they're shell commands that will insert. Various, various forms of randomization to make it probably unique. If you need to do that. That's okay. So the fetch the changes that have been made. Then it's not when it's work. So it's successful. I can also show the repository. So these are the things. It was done. So I've made, I'm alive. I have done this. I'm not implementing the SSH right now, but I'm using the user name and password using. Ask pass environment variable. And could you show us the two tags on the right hand side under the releases so that we can see that 2.0 was pushed. There it is pushed 2 minutes ago. I also wanted to know that is Jagit Jagit in the scope of the project or we will be using only get. Only using get. So good question. So, let me put a note on that. So what about Jagit. And I'm going to share my screen now so that we can see what's being typed. Make it big enough to read. Okay, so intentionally only using command line get. Conceptually, and I say it only conceptually, conceptually a sufficiently sophisticated programmer. The pipeline could invoke Jagit from inside the, the, from inside the pipeline if they were willing to, if willing to use. What is it the to, to allow access, but they should not. And I think the best way to do that is the correct answer command line get is the definitive implementation. It's the reference implementation. It's the one that has support for large files it's the one that has support for the most options has support for best support for sub modules. All those things are our reasons to stay away from Jagit. Now, we could ask. What are your thoughts on his experiences with Jagit. Last year. And so, so my, my experience with Jagit was particularly my interest with Jagit was particularly in perspective of its performance as compared to command line get. Yes. And do we want to share what we are okay so we saw that we are taking this faster for smaller repositories and, and we put that estimate around for repositories less than 50 and the Jagit was performing better than command line get. But after that command line get wins. Big time. Right. So, how she did, did you get your, were there other questions you had needed to ask that I didn't get into the notes. I just wanted to know the project structure is like we will be implementing the get credential binding in the get client login only. And I don't want to implement it in the get plugin now. Because I think the client plugin could provide some features or features of functionality that will be benefit for this implementation. That makes sense to me any objections from the other mentors. Did I did I capture that observation correctly. Yeah, I mean like we cannot reuse the code I know like that I pointed in that the chat. We cannot reuse the code we can use the functionality only like the functions like there is an author is. I mean there is a function in that which shows which version of get we are using that we can use. We cannot use the code directly because the code has to be modified between them. Like the client login uses the I like the freestyle job only like it's based on that the credential binding is based on totally on the pipeline aspect. That makes sense, at least to me that's that's very reasonable so you may get some some minor benefit by all means use that benefit that's great. So, so the prototype you showed is using username password, and it's working on Linux, right. Linux Ubuntu or they've been tested on centers for that and Windows. Did you say you have tested on Windows. I have to I have to set up the outside like I wanted to set up in like a proper development environment like I don't want to install too many VMs or do you want to put my PC. So I was like in scope like so like you can guide me on that. So, so if you're willing to use good question if you're willing to use CI dot Jenkins.io to use CI Jenkins.io, it has access to has windows and Linux, both naturally available for pull requests. So if you'd like. You want access to a wider range of operating systems and versions. Mark has a cluster with many different OSes and versions that I could give you access to if that would help. So you say that again Rishabh I missed it. Okay. And I think that would generally be available if we did if he did want to use that. I also want to make sure that we're being kind of Mark and his, his time off. Yeah, yeah, that'll be that'll continue to be available even when I'm off unless it, if it shuts itself down, I won't be there to restart it but if it's still running I could certainly give give access that for me the the first target. CI dot Jenkins.io is available now and a pull request will will let you use that infrastructure. And if I remember it makes sense. I'm sorry. I'm just saying that it makes sense to test there. Because you get both of the environments easy. Right. Well and the, the now the, if you need to do diagnosis hardship for that you'll need a local copy of windows. A machine or a physical machine. Do you have access to windows that you can use to do checks like that. Yeah, I have you and the PC have both windows and you want to. Okay, all right. Actually I got a question for you Mark. I think you have an IBM and power PC variant and things like that you typically encounter any compatibility issues there for, for these kinds of things are equally marginally safe. I haven't seen any compatibility issues there because those two machines are both running Linux variants. Now, I know of some compatibility issues for people who run Jenkins agents on s 390 mainframes using the IBM operating system rather than using Linux. But I don't have access to one of those and that it's so it's so obscure for me that I don't worry about it. Okay, cool. I figured those were all Linux but figured I'd ask I was not very. Yeah, yeah, good, good point so harsh it the things that are included there is AMD 64 arms 32 arms 64 ppc 64 le s 390 x. That's the chips. And then OS is there's Santos, Davion free BSD open BSD windows, Ubuntu. Probably missed one. You're going to need to gen two and slackware. I haven't I haven't gone that that to that level yet they. I've not had any bug reports from users on those platforms rise have I have had bug reports from users on these others. Oh, yeah so so if certainly before before the project's done assuming I'm back, I will run your code on in my environment to be sure that that it, it doesn't surprise us, but I don't think you need to worry about that and harsh it just be aware that. Yes, there are interesting variants of command line get that we have to test like the ancient command line get 1.8 on Santos. So harsh it you've you've got to check on windows and then is that part now do you think ready for your design document. Are you ready to describe. Hey this is how we're going to approach this when we start coding when the coding begins. Yeah, I need to go through the code once more than I will be sure that I'm know what I'm doing. Okay. Also, in the previous meeting we like you said in the previous meeting and I missed something harsh it could you say that again. One second. Just missed it. So in the previous meeting we were just one were curious about how this will work in the freestyle job. How the potential potential binding plugin is used in freestyle job and how the functionality damn providing could be used in that. Can I share my screen. Yes, go ahead and share. Oh, proof that Justin was right. Okay, when you click at what happens. Yeah, it works. It will work actually there is no in doubt in that, but I don't want the user to interact with this, because the gate plugin already provides so much that this. Well, except that inevitably when I've told myself. Oh, I don't need that. Some Jenkins user has proven me catastrophically and completely wrong. But I don't know what this means still I'm not sure how this will work because what if you choose to add a build step now that is a is a batch file. How does this binding know that it's contributing to a batch file, rather, you know, I, that's a that's a piece that I'm not sure how this is actually going to work. I've never used it. So I don't know how it will actually work. I assume it, it must work with the environment variables that you say it's going to that it says it's going to pass. I just don't quite know how. You can execute this. I mean, you have to use the bash command and then it will, I guess it will work. I'm not testing on windows. If you, if you click the list of available environment variables down below and open that up in a new page. What does it tell us does it include. Oh, that's I, well, is that just the standard items. I don't see any credential kind of thing in there yet. If I recall correctly, I think it runs through all the plugin environment variables that that you have. Pick up provincial binding. Okay. So in the binding setting that's up above. There are two checkboxes one seems to say, what was it it was saying something like specific credentials or Oh, I see. Okay, so that that lets you. Yeah. Okay, so back to specific credentials. So what I don't understand is how did how do you define what the bindings will be what what the environment variable is that's bound there. And the interesting I, I still don't understand this but Justin I suspect can help you with it and we go forward. I wonder if you just just for interest, would you be willing to do an experiment you're running on the next right. Yeah, so delete the execute windows batch command and add an execute shell. And in that shell put ENV pipe to sort. I'd like to know what environment variables are are made available now save it and run it and let's see if it will give us something that looks like a link to the the that credential. I'm trying to absorb as much of Mark's brain while he's still with us. Sorry, am I am I distracting I apologize if this. No, this is great. Okay, look, get ask pass equals. It's mask. Right right which which we would expect it to be masked, because it's probably not very happy that we're trying to display that thing. But it says that okay if you scroll further down is there anything else like that. So now what you could do because, because that's going to point to the file that you're writing out right. I think so. Where are we currently writing this out to you. Yeah, so unmasked value. We could, we could turn off screen sharing so that so that harsh it's password is not displayed. And then you could do a right after right before the ENV you could do an echo. Dollar sign open square bracket or open curly brace SSH under get what was it get SSH as pass close so that you could see have it output the name of that file. I think it'll mask that too. Oh, oh, it's trying. It's being sophisticated have but but it, the idea is, even with freestyle you've shown that, hey, it definitely is injecting that variable. So what you could do is add that echo statement, and then you could try and do get fetch. Oh, right, right. It will work. It will work. Oh, so you've already confirmed it works. No, I don't, but I'm 95% sure it will work. I am not tested even, but I am sure it will work. But I can test it right now. And Mark, since this wasn't sorry while you're testing this hardship, I thought I'd ask Mark question but please interrupt. I would assume that this would be probably lower on the priority list since it wasn't necessarily initially in school. Is that a fair assessment. Yes, absolutely. I think if we if we if we if harsh it's able to implement username password and private key for that power shell and CLI and SH that's in pipeline that's already that's already achieved what I had envisioned as the objectives, particularly then the challenge of testing it and all the configurations, ensuring it works. Automation of the tests. This is a particularly challenging area for test automation because doing authenticated things in test automation can't be you can't share credentials to real GitHub repository so you may have significant work to write automated tests for this hardship. If you get client plug in there is a framework that I used for test automation that we could for credential based test automation that we could discuss. I don't know if it's actually something you want to consider using that thing because it was sort of an ugly dirty trick that I use that only worked on my local environment and I accepted it was a dirty trick. And I'm sure there are much better ways to test credentials than what the technique I used. Mine was just that it worked for me. And you just use that locally. That doesn't work on like CI that jacuzzo. Right what it did is it relied on a specific file in a specific location and if it found the contents of credentials in that specific location it would iterate over them and use them for tests. Gotcha. I think it was a very dirty technique knowing that, hey, Mark keeps sensitive files in his dot SSH directory. So how should you've you've your it looks like your prototypes working well with username password. Are there. Have you had any chance to explore private key. No, I have not explored it yet. But I have done it before I did. I like I have message in the chat once like I figured out, we could use the bouncy console API for that. Very good. Okay. And I guess a question from from me to you is, as part of your design document, do you want to give some thought to how will you test this in an environment that is that is as public as CI Jenkins.io is where you can't put your credentials into it you have to find some other way to do it. I think that if I understood correctly, that means that she would have to add some new functionalities to the already existing testing framework, automate the test cases for credentials. And that is considered apart from the development work he's going to have. I would think so, either that or okay, we could take the the classic approach that was used in the get get get plug in originally where for the first 18 months of the life of the get plug in there were zero automated tests. But that's that would make me very uncomfortable. There are no automated tests for this new capability. So, how is that something we should explore during this phase during the community. How much can be covered for the coding phases. And if that's the case, then could we drop. I'm not sure if you would like that. Yeah, good point. So the question I had with this was that. So, currently, how should they is exploring using a password credentials is built a prototype is investigating further. So, do we want him to explore both of the bindings and how they could potentially work and have a working prototype during the community running phase only so that he has a good sense of what challenges going to face for the coding phases. And, and apart from that, also, if it's possible, he could look at the testing framework. Maybe he could look at the existing way you've tried to automate the credentials test cases where you have to consider dentures as well. And then he could give us an estimate and how things could go further. Because I think that that seems that seems like an important if they're not sure how we're going to test it then the life cycle of pushing into production becomes how do we plan that we're when we're going to, let's say, have our first binding in place. Good, yes. And passphrase protected I think was another one wasn't it hush it and I believe you had done some work on passing passphrase protected private keys as well. So we shop I think you're right that that is your question is much more important than whether or not we get to tests. Oh, and that's a good one Justin's got a good point could we. Is there anything we could borrow from the credentials binding plug in because it probably is doing some form of credentials tests right. And I wonder, I don't know the maintainers of that lurk somewhere where we could ask them if we can't find that ourselves but I'm sure we can figure that out to in terms of like those folks lurk anywhere. And they may they may actually have opinions on design to, you know, if we once we have a design document. Right. Also, I had one more question. When we, when we're talking about releasing get credentials binding. When we, is it necessary for us to release both of the bindings at the same time or are we willing to first reason and password and then iteratively work on SSH. That's a very good question. Should we, should we plan to release one binding, all the way to production, as soon as possible. That's that's a that I think is a brilliant idea to say hey look, here it is let's get it out there and get feedback on it. And I have an administrative question. That's a follow up to that one. Mark, do you have backup maintainers who you would want to kind of usher something like that through or is that something that would be better to like, you know, if you're out for surgery during this time then we try and get this ready for you for when you're back. No, no, I think we we do have backup maintainers so let's let's take a look at those. So, Bobby sandal. I believe Oleg is also a valid backup. So let's I know Bobby sandal and I know that let's just look at the list. There's a reason why we did this get client plug in. Who are the maintainers. And Bobby, Manuel Ramon Leon. So yes so Ramon Leon. Okay, so primarily go with those folks. And if either of them cannot then there I think there are even several others those two are designated maintainers that I got agreement from their, their that they're willing to be maintainers. Yeah, great. Yeah, I saw there was like, maybe another person on the list too but I also wanted to figure out to ask the question explicitly so. Oh yes Olivier, you're right. And Olivier is also also willing. Yeah, and he's so we can assume that these lists are good. Perfect. Yeah, yeah, and I had, I had definitely confirmed with all three of those people that they were willing. Now Olivier is an interesting because he's based in Australia, we might. He may even respond and be interested in being a mentor. Don't know. He's he's got, he's a jetty project maintainer all sorts of projects he does so we may not be available. Cool. Okay, so so harsh. What do you think of that idea. Like we are testing, like we are talking about the issue, what Richard said, like releasing the first binding before releasing them together. Yes, so, so consider releasing username password for instance, and getting it out to the world. Just as soon as, as soon as coding phase starts and you can get it implemented, get the tests tests created, run some interactive tests. Then, then with that pull request merged and asked that to be released, because the other incentive for that is get client plugin releases about every three months with new J get versions. And there's a pending J get, J get version. 5.11.1 has not yet been delivered in get client plugins so we're at the point where I've been testing it for several weeks it's just fine. Once coding phase starts, there's a great excuse to release one binding. And that'll also include J get 5.11.1 or 5.12 if it's released by then. It's fine by me. I can do it. I can at least work, work out the user and password credential binding. Good. So Justin on your question. Bobby Ramon and Olivier are backups for security as well. That's perfect. So, so that's part of their responsibility as backup so if there were a security issue for instance something found in. Some time ago we somebody found an issue in J get we had to roll because there was a J get security issue and we rolled. And if that kind of thing happens, the maintainers will be contacted and usually they'll want to deliver the security fix with nothing else in it except the security fix. I've unfortunately been part of a process like that. You've been there. That's good. I've been there with the Jenkins plugin before. Yeah, and I'm specifically kind of thinking about, you know, we're writing out files and stuff like that so. Right. Well, and that's a good, a good thing for the automated tests here is we are the automated tests probably need to to assert that the sensitive information only exists on the disk for as long as it is expected to exist. In other words, after the with credentials block exits, the, the sensitive, either username password or private keys should no longer be on disk. Again, that makes an interesting test case for you harsh it on how do I check that you could look at the see the get plugin tests of pipeline code for another example for different examples of testing pipeline from inside a Jenkins unit test. Like in credential binding plugin, there is a class name unbinder, which is a callback. So when the pipeline execution is complete, I mean the script, the code in the with credential block is completed, the callback is called. So I'm pushing, yeah, I'm pushing the, the unbinder function into that and it will automatically delete the file that has been created on the disk. Excellent. And I like that very much and I'm such a jaded skeptic I like it when I have tests that that confirm that. Okay. But but that's that's excellent that says that when creating when the credentials binding plugin was created they thought very carefully about that. Good. I'm glad you've seen that. That was going to be one of my questions is how are they doing that. Harsh it any other questions from you. I don't have it. I have a question. Yeah, so my question is that from my experience last time, during the community, I never thought about giving an estimate on how much time I would take for us to release a particular feature. I'm not sure if it's a right exercise but if if her shit is going to focus on developing a prototype and then looking at how the test testing framework needs to be modified. And do we need to also answer after doing both of those exercises that how long can we take to push one of the features that suggest the username password binding to production. Do we want to give an estimate so that we know for ourselves that how we're pressing throughout those pages. It seems like a good metric to understand our purpose. I like that. I think that. Yeah, so setting milestones and then say okay we think we can harsh it thinks you can get this much done by this point. Yes. And then you can be like. Go ahead. Just a name. Oh no I was just going to say then, maybe, you know, for milestones, we can put those kind of in priority order. And so like the freestyle job can be towards the end. That kind of stuff. So the idea is something like this pipeline with username password with tests. And then or maybe it's without test just interactive and then same thing. Tests for that. And then release in our interactive test. Those kinds of things is that what you're what you're thinking, Vishab. Definitely yes functionality then the testing and if we figure out both of them, then I think we can have an estimate. Right. Oh, another piece document. But then what I'm afraid of with this approach, maybe a drawback I'm not sure is that if we're focusing on this particular binding and it's testing and then. Is it safe for us to leave the planning or maybe the research part of prototyping of SSH authentication passphrase of private key at the latest stage of the project, or should we, is it something that needs to be explored. And then this phase so that we don't hit the roadblock during the coding phases, or maybe when you're gone during that time. And I thought that that harsher to describe that he wanted to do private key explorations during community bonding as well we are, we're what we are, where are we in terms of time we're a week and a half in. Another week and a half before. Let's see Google somewhere. Let me look at the timeline just to be sure. I'm June 7. June 7 coding officially begins. Ah, okay, so we've only got. We've got just about two weeks before coding begins. Right. June 7 is exactly two weeks from right now isn't it. No, two weeks from yesterday. Oh, no, two weeks, sorry, roughly two weeks from now. So how should what's what's your plan in terms of exploration in the next two weeks. So I have so right now I'm designed and I will first focus on the testing part of the user of the user and password binding and then I will go to the SSH binding and for now, and I will focus on the testing. So major focus is on testing for me. Then I will shift on the SSH binding. So, and I think I think Rishabh had a good question. Should we rather focus have you have shift invert that so we have you focus on the private key first to explore it and then come back to testing because for at least my experience with finding ways to do the test automation is but it was quite often it took me a lot longer to find a way to do the test automation. Whereas if if a rapid exploration of private keys shows a problem that that's probably much more important to us. Rishabh was that that was what I thought you were suggesting as well. My, my, my thought was if you're willing to consider doing the private key exploration first. That would that would that's probably higher risk to successful project completion, then the automated testing is. I mean like for now the user and password binding is only working on the line next I have not tested in the other. Right. You want me I can. I mean if you want I can shift to SSH private key. Well, but I think you've got a good point windows is also a big risk and windows with username password is certainly since you're already on username password that's a, that's a good thing to check. Even before before test automation as well. Does that does that seem reasonable to you harsh it. Rishabh any other or Justin any other topics. I guess we need to decide on our next time when we're going to meet. That was my next topic. Very good. Unless anyone has anything else. So it's Wednesday morning today what is your Friday morning like harsh it and Rishabh. So this same time, instead of today Wednesday but on Friday. Sorry harsh it I didn't hear you was that okay for you to. Yeah, it's okay. And Justin for you and me. Thursday evening. Is that okay for you. Oh no, I actually had something go on on Thursday evening. But I do want to make sure that you guys still make progress so I don't want to hold people up. Well, and we can certainly meet without without one or more of the mentors it doesn't have to be so long as harsh it's here and at least one of the mentors is here we can go ahead. Yeah, you remind me I may have something yet. I've got something on Wednesday so if we if we shifted it later on Friday your time harsh it does that still collide with school schedule. You have Friday morning classes. But I can take off. No, no, no, no we shouldn't that would that would boy Google would be so ashamed of us if we had you take time off from school that that I would probably get all sorts of rebuke. Okay then let's go ahead with Justin, let's go ahead with Thursday. So then, so Thursday for you and me Friday for for harsh it then next week, and I guess we'll we can know we probably can't determine is this day workable for everyone next week so seven days from now as well. Yes. And Justin next Tuesday works for you. Yeah, let's just check my calendar is personal calendar looks green. I think we're good to go for next Tuesday. Great. All right, so I will put us a time for next Tuesday and put us a time for Thursday for. Yeah, sorry the welcome to international times Friday morning for for Rishabh and for harsh it. And it's Tuesday our time right. Correct. Yes, shame on me right. I just call everything out in UTC would that be better. The calendar works. Yeah. Okay, so you should have invitations in your calendars for now. The next is Justin we need to send a request to the, to the Jenkins advocacy group, asking that you be granted access to the Jenkins zoom account. You can host these sessions when I'm not available. Yeah, that sounds good and I don't know if you want it to like chat separately like about administrative things are on that or anything like that. Happy to do that or we can figure out how, however we want to. If there's anything else that I need to know about but I doubt that it very much. So, they think also work. Excellent. Yeah, I'll probably the things that that are most important I think will come to you from Oleg and the org admin team. Okay, cool. All right, thanks everybody. Anything else before we end. All right, thanks harsh excellent progress great to see your demo. Thanks very, very much for your exploration. Talk to you in two days. Okay.