launchCommand("git", "clone", <url>);
Hi all, Git Plugin GSoC Project 2020 Second Weekly sync is about to start in 20 minutes:
Zoom Link: https://us02web.zoom.us/j/87507840768?pwd=UVljaS9YeVVKd01Rd0FCc1FCaWRMQT09
@rishabhBudhouliya @MarkEWaite @justinharringa @omkar-dsd @fcojfernandez Please review the LinkedIn post draft:
Git Plugin Performance project update by Rishabh Budhouliya: bench-marking of Git client implementations and a new GitToolChooser engine which recommends a Git implementation on the basis of the repository size.
"What we’ve learned so far in this project is that a git fetch is highly correlated to the size of the remote repository. In order to make fetch improvements in this plugin, our task was to find the difference in performance for the two available git implementations in the Git Plugin, git and JGit. Our major finding was that git performs much better than JGit when it comes to a large sized repository (>100 MB). Interestingly, JGit performs better than git when size of the repository is less than 100 MB. In this phase, we were successful in coding this derived knowledge from the benchmarks into a new functionality called the GitToolChooser".
#jenkins #git #gsoc #performancetesting #jmh #benchmarking
Some points of discussion:
Currently, only at the level of
CliGitAPIImpl (implementation level) the information of whether an operation is supported or not is held and the decision to throw an exception in case of calling an unsupported feature is taken there only.
Now the issue is that GitToolChooser needs that information before recommending a git implementation. @MarkEWaite I think it may not be possible to take this information from the implementation as it assumes that a client has been created by the time those methods are called. (Even the decorate-xx methods expect a git client).
Hi all, I've been facing some difficulties while creating a generalised way to get the information related to the compatibility of a git implementation w.r.t a git extension.
@MarkEWaite In the discussion we had,
GitClientimplementations were the best place to access the information we need.
The issue with that approach:
GitCommandinterfaces like the
CheckoutCommand. These interfaces collect the information which would tell us if a certain extension is implemented by JGit or not.
LFS pull is supported by JGit or not, I would need the field value of
String lfsRemotewhich is set in the CheckoutCommand implementation within the client.
GitToolChooserto make the right choice.
Hi all, I have created two new pull requests:
rishabhBudhouliya/git-plugin#6 -> In my forked repository, it contains the addition of UnsupportedCommand feature in git plugin only
jenkinsci/git-plugin#937 -> In the original git plugin repo, it contains GitToolChooser source code + UnsupportedCommand feature
Hi all, Git Plugin performance improvement Weekly Sync will start in about 30 minutes:
Meeting agenda: https://docs.google.com/document/d/1ov4ug9WfbcTYNHL1DBcsxyRKgCi7EnFVIywdiP36CSk/edit?usp=sharing
user credentialsto get size of private repositories -
CredentialsIdso that then the plugin can match the appropriate credential.
We will have the GSoC project second weekly sync in about 30 mins:
username:passwordtype of credentials for a freestyle job with a personal private repository, GitToolChooser is able to recommend as expected.
@MarkEWaite I was unable to find a functionality within the Github branch source plugin which would allow us to search for valid credentials with just the
I will be exploring more branch source plugins to find a workable solution for our case, as with this change, the responsibility to provide credentials is on the git plugin which might limit GitToolChooser's ability to recommend tool in certain cases. (It will only work for username:pwd credentials)