There is no way to force the plugin to use clone instead of fetch. Even if there were, it would likely have the same problem, since clone is often described as "init + fetch".
You could reduce the amount of data transferred by using a shallow clone. That's one of the checkboxes in the "Additional Behaviours" section. You could reduce the amount of data transferred by retaining a reference copy of the repository on each slave agent. That's one of the checkboxes in the "Additional Behaviours" section. You can reduce the directories checked out with a sparse checkout, if you only need a subset of the directory tree. That doesn't reduce the amount of data transferred, but reduces the time needed to perform the checkout. I'm not sure why it is running the fetch with the full ref spec initially. That seems like a bug. However, it would need more investigation, and you probably want to reduce the amount of data transferred now. To reduce the amount of data transferred immediately, use a shallow clone. Mark Waite On Tue, Nov 3, 2015 at 2:47 AM Marco Sacchetto <[email protected]> wrote: > Hi, > > I am trying to get a repository cloned inside a Jenkins job. The cloning > operation works, but the downloaded data is way too much, and we are having > issues since the site is on low bandwidth and the programmers want the > workspace to be cleaned out at each run. > The git repository needs authentication, and I only need the master > branch. If I try to run a clone operation manually from a console, it > downloads around 3,5MB of data. When the git repository needs credentials, > it seems that it automatically switches to using git init + git fetch. Git > fetch, though, downloads around 100MB of data for nothing from the > repository. I then set the refspec setting to > "+refs/heads/master:refs/remotes/origin/master". If I try to run a git > fetch manually from console with that refspec, once again I get the correct > 3,5MB of data that I need. > > The Jenkins Git plugin at this point behaves very strangely. What I see in > the log is that it first runs: > > "/usr/bin/git -c core.askpass=true fetch --tags --progress ***repository > url here*** +refs/heads/*:refs/remotes/origin/* # timeout=30" > > and only after that is done it finally runs a > > "/usr/bin/git -c core.askpass=true fetch --tags --progress ***repository > url here*** +refs/heads/master:refs/remotes/origin/master # timeout=30" > > This means that, deleting the workspace everytime, I still need to wait > for all the 100MB of data to be downloaded again every time I run the job. > Is there a reason for this behaviour? Is there also a way to inhibit it, or > to force the git plugin to use clone instead of fetch? > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-users/10e38af4-0365-4a41-8fb1-8d2e641ee1d4%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-users/10e38af4-0365-4a41-8fb1-8d2e641ee1d4%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtGCYR5-W5EkvLQ4RBYL65iEN%2BM%3DBFkODn3ym5w3UY1k5A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
