Jenkins Platform SIG, 25 Aug 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2020 08 25 GSoC Git Plugin Performance Project

Description

Jenkins Google Summer of Code project for Git Plugin Performance Improvement. Reviewed the results, approved the release of git plugin 4.4.0 with the git tool chooser implementation

A

Hi everyone we will uh discuss uh what we're going to present for the final presentation in our work product, which is going to be evaluated by the mentors.

A

So, firstly, I would like to discuss the results we've got from, so justin gave a brilliant idea of so I had the results in my local instance with the mac os operating system and justin gave me the idea to do the same thing for multiple platforms, so that we have a larger variety, a larger size of data, which is always a great thing. So so I I created three pipelines these three pipe. The first one is checking out.

A

uh The spark repository spark is around 500 mb, uh then the second project, uh the get to testing two project, is uh checking out uh tensorflow, which is around 800 mb, then the third one I am selecting is checking out is gate plugin, which is around 20 mb. So what I wanted to see was uh when the threshold is okay, so I also have to talk about one more thing. I should talk about before talking the results, so I was the size rule. We have within the get 2 chooser right now that is 5 mb.

A

So within the 5 mb limit we would provide jg. We would recommend jk after 5 mb. We would recommend get so off lately. I I saw a lot of results uh where uh in the benchmarks, where for repository sizes like uh 20, mb or 40, and we are 50 and we have a seeing that j git is performing better than gate and by some margin that that margin can be, let's say, 40, milliseconds or maybe 80 milliseconds.

A

So there is a considerable not in terms of real performance but in terms of our theoretical experiment that the gap was there. So so I uh that the jar which is uploaded in this instance, it contains, uh has an increased size limit to 50 mb instead of 5 mb.

A

So let's just start with git plugin how how it has done the git tool chooser so um so, first of all um the user has. The assumption here is that the user has chosen jgit and now the projects have been checked out, and I just want to show one more thing before showing the results, because I want to confirm that my process of uh testing this experiment this creating this and performing this variant is right. So this is the thinking file. I used to do this in this gentle jenkins file there.

A

I am not performing anything, it's an empty step, but it checks out the repository. So I just wanted to check out the repository and do nothing. I did not want a even build process or anything, and since I had a project where uh the matrix where I have a matrix, which runs on multiple platform, but it builds on maven, I just removed that step, and I use this is: is this wrong in.

B

Any way it's it's, it's not wrong, but it's got a problem that I would expect you to get a failure on windows. It will say I can't find sh if you're just changing yes. So if you change it to echo and say echo hello world, then you've got a platform independent step, but other than that this looks great and I can tell you centos 8 is always clown hosted.

B

Debian 10 is almost always cloud hosted and windows. Computers in my environment are all modern. They are all within the last three or four years, so those three are are quite predictable. Freebsd 12 is older hardware, but given that you're, probably network bandwidth bound, it may be fine.

A

And what, if I.

B

Remove the asset step, it's just an empty step that also be okay. I would just put the echo in because I'm not sure that declarative pipeline will accept an empties, an empty step. It's it's cheap.

A

I think that's what I tried: first, okay, okay I'll do that. That is, that explains uh some of the builds we failed so um so now what you're seeing here is uh the third build. If you look at the third build uh that is done without j get in one. Second, I'm just gonna just give me a second.

B

Oh, and are you is this doing something that will allow it to wipe the workspace? So it's not reusing a workspace. Yes, okay,.

A

Great yes, I I have added the additional behavior wipe out clean workspace and force re-clone that behavior great yes, so, um okay, so the second build is without the get tool chooser and the third build is with the get to user.

A

Now, uh with centos 8, we do not see any change, and since we are looking at now, the the our our measuring unit of the metric is seconds. It's not milliseconds. So in milliseconds we would automatically see uh differences that that I've seen with the benchmarks, but now since we're talking about real cases, and we want to show real results, we will talk about seconds, because that is what the user might see and- uh and in that case, in centos, we don't see any difference in debian. We do see a second difference with free bsd.

A

I think the build failed. I'm not sure why this happened. It took 10 seconds. It should not take 10 seconds for uh any. I think machine to copy get plug-in the checkout git plug-in clone. So uh so I'm sure so what I can be sure of is that there is. There will not be more than a second difference when we are talking about reposit reported repositories less than 50 nb.

A

So because one might ask in our final presentation by representing it, a user might ask what kind of so our performance improvements are the bigger performance, improvements or the or the more attractive results we have are from the area where a person when it chooses the jget implementation, then we are able to uh provide a better implementation and give a much visible result, but in general, when a person mostly uses of what I uh knowledge I have a user, would not the user would go for the default implementation, and I assume that the default implementation will mostly be get because git is installed in machines commonly.

A

So in that case, for most user, the change in performance will not be noticeable. It's. They might see a second difference. They might not. I might need to perform this, this experiment repetitively, so that I see so. That is when I can be confident that I okay, I know that within 50 mb there I can. I can see that there is a reduction of one second or maybe half a second or something like that with windows. Also, we see that it's it's the same in in the benchmarks.

A

I've uh if I created- and I ran, uh there's almost a half half a seconds difference when we're talking about it ranges, but if we average the results, it's almost it varies from half a second to, let's say three, fourth of a second. So that is why it's it's unlikely that we will see uh any noticeable performance change.

B

When we're talking about but your measurements, you show that even for a repository is relatively small, like git plug-ins, there is a benefit in terms of clone time to use jkit. That's.

A

Good, yes, yes, there! There is because, because the the the most important, the vital insight we uh derived from the benchmarks, was that for a small repository because of the um because the jvm heats up and jkt is a java implementation, it performs better so so that advantage uh makes jgate a better contender for smaller size repositories than kit. But in general cases git will always perform better and in large size repository uh cases it would exponentially perform better than jk.

A

So so because when I was creating the presentation, I was thinking what would I answer to a person who would ask for most of the users what would happen because for jay gate we we have great results for jget and I'm going to show them to you, but I was I was. I was worried that would that be enough uh for us, so so this this project was focused on us, a repository size less than 50 mb. Now, uh let's look at uh something larger drastically larger.

A

So this is a 9 800 mb repository almost so here. The fourth build the last build, the latest build is, is a without get to chooser build and the previous one is with git tool choose it. So if you look at any of uh the platform for till freebst, there's, there's 50 deduction in the execution time checking out process uh yeah, and it's more than that for this I know it's it's almost it's actually more than that for this one freebst and uh but with windows.

A

I I saw this and I could not understand it actually reduced without get to chooser, which I did not understand.

A

So I I am actually not very confident with the results I have. I may have to run some tests, particularly on windows, if it's showing this behavior consistently.

C

Riship on the windows is get cli installed like this to confirms.

B

So there are, there are all sorts of potential variability, because we're he's testing in a in a live environment that has four or five windows, computers.

A

And well, we can check that out. The recommended get tool is gay and I am so it is using get hair with the build with the uh the results we've seen. So, oh, oh, that does.

B

Have gear and yes, don't forget, we've we've now been a month or more since we talked about it, but in your final presentation, don't forget to highlight that avoid. Second fetch, for some users may be a substantial improvement already, it's just just dodging the second fetch. We had reports from users that it was very that was slow, even if they get no other benefit. They get benefit because we're doing one less operation.

A

Yes, I I I have included that in my presentation, because I I was desperately looking for points to to show what we've done. So I I did uh include that so um so I I think this uh this result um somehow uh confirms that there is, let's say around about 50 degrees in so 50 improvement when we're using it to choose it, but in a particular case- and I think we'll have the same result with the get tool. Chooser testing project, which is checking out the spark repository.

A

It's actually not the same here. What we, what we, what we can see is this. The tenth build is with the get two chooser and the latest build is without one so for send to us. It's almost the the time reduces 10 seconds or whatever. It is two. It's not even 10 seconds, it's less than that.

A

So this is, I would say, surprising, because uh the benchmarks I have I performed throughout the project for three months, I saw um improvement in order of 150 160 when we shifted from git to jacket for large size repository like 500, 600, 700 that reduced to 50 percent here when I'm actually doing this end-to-end. This is not just the get fetch operation isolated. This is the whole uh get plug-in performing the complex operation.

A

So I somehow um I justified that this the reason of not seeing the same exact result with what we saw in the benchmarks here, with uh with the fact that this is this is now not just a single isolated operation, but I'm not sure why this would happen why we would have lesser reduction here so again. This is why I'm I'm actually not very confident with the results. I am confident that there is a reduction and it's around 50, because my local instance is giving that for five or six jobs.

A

I've seen and it's almost consistent with that result, but here in this instance I'm not seeing that. So uh maybe I need to run more jobs and then add those results to the presentation.

B

Actually, I would just I would just admit that in a very repeatable environment, you've confirmed these results, however, in the wild or in in in environments that have widely variable equipment. The results are also widely variable. I'm not overly concerned that you need to run it again. I think large variability is predictable in this environment, where you're te this. This is not too different than if you were running these tests on ci.jenkins.io, where you don't know what class of agent you get you you just get an agent that has the label.

A

Okay, okay, then I can yes, I can include the results and I can add that kind of a node that the environment we are testing in can include a lot of variability, so uh so okay, so I think uh these are the results we have from the get to chooser, and this is what I will be presenting in a different format. I was thinking graphs comparative bar graphs, where we see uh I'll I'll ensure that the paragraphs on the slide only so uh okay I'll go to the agenda once.

A

So uh mark I just wanted to ask uh whatever testing we've done. Are we still do? We have any case where any compatibility is breaking a use case is breaking for after adding it to choose it. Do we have any cases like that, or are we left with some kind of testing.

B

So there is, there is certainly still more testing to do, but the testing, I think that needs to be done is not not as much about compatibility as about the change that that using jgid brings on the master or on static agents where, on the master and on static agents, now we're running in process and we're relying on j git to do a good job of garbage collection right. If, if jkit has a leak it could it could critically damage the the jank, the jenkins controller, the central master?

B

If I'm not aware of any leak, I've not detected one, but that's. One of my concerns is if a if a controller that previously was managing a thousand repositories or a thousand jobs, suddenly develops a is exercising a memory leak in jet that didn't exist before, because they were using cli did. That would be a serious problem.

B

Those are the only kinds of things I'm I haven't seen anything compatibility wise and if we do we'll fix it in an upcoming release,.

A

So I think that answers my question of increasing the size limit to 50 mb then right now we would be. It would be safer to release it with a 5 mb size, because that would make sure that we do not. If we have something like that, a catastrophic memory leak issue or something like that, then we would. It would be safer to release it with 5mb, because that would not cover as many projects as a 50mb size limit would, I would say, with a 50mb limit we would maybe cover most of the cases.

A

It depends on the use case, but so I I have the pr ready to increase the size to 50, but if, but I I wanted to ask, do we want to do that right now before releasing or can? Should we do that after releasing it.

B

So I like your argument that we wait till after release. You could cue the pull request you can still be submitted, certainly, but I think let's go with the current the tested values just to to see the the bigger danger here is that we're going to this will be deployed in within two or three weeks. It will probably be deployed in 50 000 installations, and that's that's only 25 of the the installed base, but 50 000 installations and those installations will have have conditions that you and I haven't even dreamt of yet yeah.

A

I understand okay, okay, so we'll go with that then, and uh so do we have any other requirement for the release.

B

I'm not aware of any uh unless fran just in our own car have any. I think we're ready to ready to deliver a release.

D

Gonna need a celebration. That's the only other requirement.

A

A

Okay, so um I think we have some time left, so I think we can talk about the presentation, so we have discussed the experiment. I've done for uh for measuring the time, and so I was also thinking do. Is there anyway? Can you the mentors? Can? Is there any other way? We can show the results, except um so is this: the is this.

A

The best way to uh to be as near as a user would expect the results to to show the results which are as near as a user would expect once they have this feature in their systems to just measure end to end the time which is being executed for this process.

B

For me, I think that's closest to what the user wants as some at some point in the future, not not for presentation, but at some point in the future. I think users would appreciate an online guide which would tell them in addition to these results, if you use a reference repository things get this much better.

B

If you use a narrow, ref spec on a repository, things could get this much better. So there there are things there are other things that are candidates, but for for purposes of this project, I think presenting the the time to do. The operation is the right kind of result, at least for me as a user it it it talks to me it tells me what I wanted to know gee. Will I get a benefit from this? What are the risks of doing this.

D

And how do you get the benefit right? Do you need to do an extra thing here and there to get extra benefits.

B

Well, actually, justin's got a very good point there. Most users do not have jgit enabled, so they will get no benefit from this, because I suspect most installations did not even enable jkid. So in order to get benefit, we need to remind them. You need to enable jb.

A

But but then, if, if someone doesn't even have jgill and they have gate, then why what benefit would they get if they already have the performance, uh small small repositories.

B

A

Smaller, yes, right, small repositories.

B

Clone a little faster, yes at the so for me, one of the surprises was I had a pipeline that uses a pipeline library and it would intelligently choose jgit to clone the pipeline library and then intelligently choose git to clone the repository. So I got a little bit of a benefit already, because the pipeline library pulled in with jdid and then the the whole big project came in with command line. Yet.

A

Okay, and uh I would since uh I think um we haven't seen how the switch is looking like- I have put up a screenshot for it, but still so do we need a demo for this? I do. I haven't planned a demo. I was thinking we're just showing the results and how it's going to impact the user, but because there is not, I am not sure how we could demo this performance improvement, but justin's point that the user should know how we can enable or disable, and then what configurations would provide better results.

A

I think that much we can show in the presentation in the meetup.

B

So how much time oh go ahead? Justin.

D

No, I was just gonna say I don't know like that. It would necessarily be like demo. That'd be, could also be like screenshot, or uh I think you had documented some stuff from the readme or something like that. But anyways in documentation would be useful. I think, for the long term, for this purpose maybe screenshot or could be demo or something like that, but maybe mark had a idea too.

B

Yeah I like show the show. The documentation is also a good excuse to brag that, yes, we're doing documentation as code. We wrote the documentation before we released the product, but that hardly ever happens in most software. So so.

B

Okay, there, it is yeah this one. Unfortunately, this is this is a place where you're really begging for the new table to give ui, because you notice that the help buttons are completely invisible on the right hand, side of your screen. Yes, yes, because of because of the table layout, that's used here. That's it's a terrible thing on this particular yeah, but I think your screenshot that you embed in the documentation is perfect, show it and and bring up the documentation. We should brag to people that, yes, guess what this is documented, please please, no!

B

You can read about it. Okay,.

A

Okay, I'll do that: okay, so.

D

One thing that I'm wondering about- and I don't know that maybe this is a question that would come up too, is like. I wonder if it would make sense or if it'd be possible, to have jay gate enabled, if, if this proves to bear fruit for tons of people like if that's something that could be done at some point to automatically enable jay get jenkins because it comes, you are.

B

You are such a brave person. Oh my sakes, you are a brave person asking mark, wait to change defaults as shipped yeah that I love brave. That's great! I'm not ready to sign up for that. I haven't been stabbed with as many spears as you in.

D

The open source.

B

Community, just the number of times people have complained to me about shoot any change of defaults. It's like no. I had this awful evil default, but I love it. It's my favorite.

D

Maybe that's the answer. If that question comes up to you is like right, a lot of people have strong preferences that they prefer not to have.

B

Jade enabled, but they yeah this is, they have to make an active choice, they must choose uh and if they've chosen not to enable jet, we won't override their choice.

A

That's right, and on top- and on top of that I was thinking that maybe we can. We can also add a feature where we don't even ask the user for the implementation. We ourselves figure out what is available and then recommend the best thing there is, but I I think that is not um we shouldn't do.

B

That, because you you win extra points, you're even more bold than justin is that's great. Yes, the warnings in the log.

D

Warning you do not have jay get enabled. Are you sure about that? We're at no room.

B

We just turn it on, for you.

B

Truthfully there is, there is something to be said for things like we probably ought to warn people. Oh you're running centos, centos, eight, your git command line get implementation is an old boat anchor. You should you should upgrade, but your centos, sorry, centos 7, is the really the road anchor centos. 7 is running a git from like six or eight years ago, and you know the git community has improved performance in that long time. They you absolutely can be confident, but but no that's out of scope here as well richard.

B

No, yes, I think that's a great thing for the future. um It's called an administrative monitor where we warn people warn the administrator. You know you're running an ancient version of git on this computer.

B

Okay, so our offer to them, you could have much better performance. If you just would do this.

A

And uh from a user's perspective, if I'm not sure how many users so mostly, I assume that the users of jenkins product would be developers, so I'm not sure still. What percentage of them are are aware of the implementations, the two options we have within the git plugin, and that is why we always have the default option and the default option. I just want to make sure that I understand it.

A

The default option means that, if get a git is installed there, it will always be the default option, but if git is not installed, the default would be jet and the user will not get to know that it would. It would be default from their perspective.

A

B

As far as I know, if, if it will never use jgit, unless you have enabled jacob that the previous behavior anyway was, if I don't have command line get installed, it will attempt to call command line git anyway, and it will then fail terribly ugly failure message and says: get command not found.

B

So it's not nearly smart enough to say. Oh, I didn't find command line, get I'll, try, jgid, it's it's absolutely dumb. It says if you, if you ask to use the git plugin and you don't have command line, get installed and you did not enable and choose jdit. You will just get a hard error message.

B

Okay, I I. I is a.

A

B

I'm not sure I'd call it safer at all, but it's it's certainly lower change to users. It will not surprise them that, oh, I forgot to install git. They must go install git.

A

Okay- and that means then the usability of jkt is, is quite and I'll, not say remote, but only people who would know about jet or might have any use case right.

B

You need to have read the documentation and see: oh there's a jacket, implementation wow. Should I try this yeah that's correct.

A

D

Honestly, I guess, if we're, if we're looking for these kinds of performance improvements at a broader scale, you're, probably dealing with someone who's an administrator of jenkins, and so they probably will have read the documentation. In most cases like joe user who's got a little jenkins on his laptop with five projects. Probably doesn't care about it quite as much as like.

B

Well and anyone anyone that's dealing with multi hundred megabyte repositories, we hope will eventually ask themselves the question: could I go faster?

B

Is there something I could do to go faster and they'll start exploring and, and that's that's a whole new theme and a whole new topic of what are the things we could do to help them go faster.

A

Okay, okay, so uh I'll just quickly uh discuss what I want to present the structure of the presentation, so I was thinking to introduce uh the project what we wanted to do and- um and I I I have a question here- I think so, um okay, so uh right now, our performance improvement is focused and limited to the checkout step.

A

And what I wanted to ask was this: whenever there's a checkout step in any project in jenkins for any jenkins pipeline gate, plugin is the exclusive plugin which will be used for that. I wanted to confirm if.

B

They're, using if they are using a git repository, they will use the checkout scm step, we'll use git, we'll use the get plug-in. Yes,.

A

Okay- and the second question uh is the second part to that question- is that, but when we're scanning repositories scanning branches, sorry for a particular repository at that point, there's a fetch step, and then um I think we um we scan the branches. Then then we build the branches. If we want to, it depends on what the user wants to so for that process for the scanning process. That is something it's not exclusive to exclusive responsibility of git plugin. What is it.

B

That's that's correct, so the the in fact it's recommended that they, wherever possible, not use the git plugin to do scanning, because the higher level providers, github bitbucket, giddy gitlab those higher level providers, can ask the questions more efficiently than the low-level provider can. So so the higher the preference for a user should be if you're, using one of the things that has a higher level provider, use the higher level provider it's more efficient, okay.

B

So so, yes, it can be used for scanning branches, but it's recommended that they please use the higher level provider it'll, give them better results. The git plugin does not know how to do rest. Api calls to github right. It doesn't have to be rest. Api calls to gitlab and those rest. Api calls can be dramatically better than cloning, an entire repository to get it's just to get its information. You get it's yes, that is what the git plugin does right right.

B

The git plug-in is is like a stone knife, whereas, whereas the the the higher level plug-ins can use lasers and other really effective, cutting tools.

A

Okay, so uh so after the introducing the project and the then I was thinking about uh going through to the process of how we've reached to the conclusions right. We right now before introducing git to chooser of the results, because I think we don't for most of the projects and students a demo is is uh eats a lot, a chunk of their of their presentation, because them is something they have to do for their plugin. But for my case I don't have a demo there.

A

So uh I was thinking to uh use that time to uh not go into too much depth, but just just show how our results, the results we've used to uh to enable git tool chooser. uh How we've reached to that point- and I just wanted to I- was thinking of talking about um we- we, uh the parameters, we chose to see to see the dependence of the operations and the performance uh were they range from the size of the object. The repository contains the number of branches comments and tags.

A

What we got out of them, just a one line result not the problems we have had with them, but the results. The conclusion we had and and then sort of talk about, um we've also uh benched back those uh results with multiple platforms. We know that the git tool chooser will not perform unexpectedly uh in one of the platforms. We know it's it's platform independent in terms of uh the benefit it is giving.

A

We did see that with one of the benchmarks I presented in the last presentation in the phase 2 presentation, so I I was thinking of showing that as a as part of the process of how we reach the results- and I think that gives the user more confidence that our results are whatever git tools, chooser is doing is, is legitimate, and then I was I was thinking to visually, explain how and where we've improved, and I was just thinking to show that, if you're checking out a repository from one of these providers, so there's this the scm checkout step.

A

We've done two things. There we've introduced a new new feature which is get to chooser, which I want to say. I want to market it as a feature which takes the responsibility of choosing the right implementation from the user and let the system decide that, but I'm not sure if it's the right thing, because we actually order it as it is.

A

So I I was thinking of introducing it like that and then the second thing we've done is that we've removed the second fetch which is redundant in most cases, and um I would add that it was requested by users and it would benefit those users. And so I would refine this diagram. But this is how I was thinking of visually, explaining what we've done and then with the results. I would show the graphs we have the graph say I haven't showed you any graph.

A

I've shown you uh the builds, but I would I would put all of that in a graph and then I was thinking of showing. So I what what would be better to show multiple repositories varying from a small size to a large size right. That would be the best thing to do to show the performance improvements uh from a small repository and then, let's take it to a big repository.

A

And in that process explain that for a small repository, j gate is performing better than gate and then for a large depository git is performing better than j j get and that decision of switch is being taken care by uh the feature we've implemented.

A

So and after that, I I would include slides of the challenges we faced and what uh future scope or what we have to do, which, which is the last thing I want to discuss for this meeting, that we the the extension support for the extension support. We, uh I think, mark and I we both tested uh the github brand source, plugin extension implementation.

A

It is providing us the information we need with credentials or without and uh but that hasn't been merged uh in their plugin. So it's officially not available to the user. So I so I wanted to discuss what should I say in the presentation too, because that's because we ideally we want to provide that support for github git lab and get a bit bucket, but with each for git lab, we've had some issues and there is a actually a roadblock there uh in implementing the exam.

A

We have implemented the extension, but the way the credentials are passed is something which is not currently uh possible, with git plugin. Do we want to go in there and discuss the issues we've had with those extensions, okay.

B

Okay, so for me I would say we we talk about what more is needed and what's needed is we need an extension implemented for gitlab for bitbucket for giddy, uh probably for two leap, so there there are several branch source providers. That would that could provide this information from the rest, api and- and it may be you that does it- it may be them that does it, but the we've now got an api they should. They should provide the data.

A

Okay, but why would uh I think, why would they? Why would they do it? It's not something, I'm not sure, because um it's it's it's an information with the git plugin requires is, is actually it means nothing to them in terms of functionality of that plugin.

B

Oh, oh, except I think it does imagine imagine you are atlassian and you're providing the bitbucket plug-in and you learn that the users who are using github are getting better performance because the github branch source implemented this api. uh You are now at a competitive disadvantage because somebody's got a better implementation than yours, yeah. So now now for a an open source thing like giddy down at the very bottom, it's harder to say that, but for gitlab, certainly gitlab's primary competitor is not really jenkins.

B

It's github right and if, if github is doing a better job than gitlab is doing on on the jenkins implementation, users may shy away from gitlab and towards github. Okay.

A

B

A

Know that you want to say.

B

That in an open source presentation, but I'm just thinking from that for them as providers, they may say- look I don't want to be behind these other people. I want them. I want to be at least as good as they are.

A

Okay, so um that means that we will, we will discuss uh the extensions and the support we have right now and what we need in the future. To make this feature fully, uh um I would say, useful to every provider in every use case for every user.

A

Okay, so I will add that- and uh I think that's it, that's that's what I think I would present for the meetup and then I also have to present for the devops world. So I was thinking to be more concise and include lesser details about the implementation or, I would say just talk about the general improvement we've done and that's what I was thinking to include there.

B

So yeah you're they're, giving you 10 minutes is that right at devops world. Yes, it's like yes, this this slide that you've got on visible right. Now is a great opening slide for that test. I think it's not the right slide to open the the the gsoc presentation, but it's this is a great slide for a devops world thing, because it grabs them immediately. It's got pretty colors. It's got logos.

B

You may want to put this tool chooser in bigger words somewhere and and redundant as it gets bigger somewhere. You know so so, but but this is a is a great choice as an intro slide for a ten minute. uh Lightning talk, night, okay, okay,.

A

So I think that's it uh anything. uh Do we need anything more so from the google from the gsoc team? I I gotta mean that we, I uh need to uh send them the link for the work product and in our case I would assume the work product is the pull request for git to choose it, which is now merged, because I think sending the git plugins url would not be the right thing, because that is not exactly the work product.

A

The word product is the performance enhancement within it and service and and uh regarding the work product. Is there anything else the mentors would like? Apart from what is done here, any more requirement is uh yeah. So.

B

So I think, if you've got an interesting challenge, you may want to send them a link to a document which shows links to the various work products right, because we have one work product, which is the git client plug-in implementation that had to release.

B

We have another work product which is git, plug-in, pull 931 and get release 440. We have another work product, which is the github branch source, pull request that is pending, and each of those is in fact part of this work right. So so for me, it's it.

B

If, if the, if the request is a single link to the work product, then that's probably needs to be a document which actually has links to all the real products. You know the pull requests, the conversations because saying it's just get plug-in. It's not right. Your project has changed much more than just the git plug-in.

A

Okay, I'll I'll make a document for that I probably adjust. Maybe I can get up just I could do something like that and then show them. Okay, I understand okay.

B

Either that or you know what you could do richard, what if you put it on the jenkins dot, io page that describes the project?

B

Okay, I could update the project page right, because I haven't done that. Yes right and that's a great excuse to update the project page and that's a place where we can put links to multiple port requests and to plug in releases. Yes, get client plug-in, 342, git, plug-in 440 and all sorts of things like that.

B

Yes, great idea, I.

A

Lied to that I'll update the project page first, because I have to write a blog as well. I haven't done that so yes, okay, so I guess uh this is it for the presentation and uh so mark. uh We uh will release the plugin today tomorrow. uh Is there.

B

A time it will be probably so, I've got a day full of work for my employer, so it'll probably be it's after 12 hours. So thus reshop, I'm authorizing you for once in the last four weeks to sleep, sorry shop and I spent all day saturday, all day my day, saturday working on this testing and exploring it and at the end of it it's 4 p.m. My time and I realized oh, it's about 4 00 a.m. Richard's time and he's obviously not slept all night long. So yeah this is yeah it will.

B

It will be at least 12 hours before I get to releasing it think think 12 hours, because it may only be eight, but it will be after my working day today when I can get to the time to release the gift plugin. That's that's! Fine! That's! Okay! I.

A

Was just okay, so um okay, so we, uh I think we have everything covered here and uh presentation is on thursday, so okay then we'll meet there. I hope I give a great presentation and yeah thanks. Everyone.

D

B

You you will be great richard, I am, I am thrilled and you're you're right now we may we may create a firestorm if, if we miss something in our testing right and and that's that happens, sometimes get plug-in releases have on occasion created firestorms. So so don't be dismayed. If we miss something in our testing and people come back and say how dare you that's? Okay,.

A

So there there is something where I am a little concerned and that is related to um how the git tool chooser will provide the implementation uh when we are talking about expanded paths so because we are processing parts and then we're giving that we talk about implementation, but it's actually the executables path, which are which we are passing when it's when it's git, which is like slash user, been get if you're talking about the next system, so uh I'm actually a little.

A

There was a check which I added before before the final pull request, which I added to include the implementation, where there's an expanded path instead of just git, but that was making one of the builds fail in your system and then I remove that check. And surprisingly, everything is working. Fine, even the expanded path have checked that particular use case. It's working fine and so I'm a little.

A

uh I'm actually a little uh anxious about that, because I've removed the check and my unit test cases are fine and whatever we've tested is fine, but I I'm still a little skeptical of that. um I I think we might have issues if we would possibly have issues where the implementation might somehow get changed which might result in, but I'm I'm not. I'm not sure. I. This is me being a little negative and and skeptical about the about the whole uh feature and but.

B

Yes, ma'am, yes, ma'am I'll I'll. Do some initial smoke some smoke testing as well before release, because I think it's a good place if you feel concerned it's a good place for somebody else to look at it as well as.

A

B

I find some disaster I'll. Let you know yes mark, please I'll.

A

We have to fix that. Yes,.

C

Okay, thank you. Everyone thank you for giving uh this. This is uh so.

B

Shall we shall we be.

C

Covering like uh more test cases with uh more versions of gates here, maybe like after the watch.

B

That's that's certainly one one possible future activity is comparing get 1.8 ancient history to get 2.28 modern, modern recent release to see if there's something the other is. There are more operations that we could optimize like ls, remote right. It's we re shop correctly, focused on the big, the big win. The big win was checkout or the clone. You know the big win is clone it's network operation, but there are other operations where we could actually prove conclusively that jkit is good enough and silently replace it. So so yes, omkar you're right.

B

There are many more things we could do in the future.

A

uh But mark I think we we did benchmark, get ls remote uh and uh I think I have a I have a study lit. I I did quite extensively experiment with git lsm, oh good. I don't I don't remember what conclusions did we derive from that?

A

I think I'll look for that document and we can discuss that on the chat platform. I I'm not, I'm not sure what I'll send the document I'll first find it. Okay thanks! Everyone thanks for.

C

A

Much more time that is allocated for our meeting bye, everybody recording will be posted.