Thanks - I understand it's not clone per build. Also I set the topmost upstream job on a node to fetch changes from repo using git and clone the same workspace for all other downstream projects on the same node. This (I assume) prevents copies across master. But this is convention which cannot be imposed for builds@.
Am I right in assuming that copy of zip archive to master happens regardless of all the clone related jobs being on the same node? This is something I wasn't aware of. That seems bad. -- Prasanna., On Fri, Feb 15, 2013 at 07:11:03PM +0530, Olivier Lamy wrote: > Hi, > The repo is not cloned fully for each build (except when a new node is used). > There is a pull not a fully clone (except if you use option "Wipe out > workspace before build"). > So that must not be so slow ? > My issue with this plugin is that it will generate some overload on > master (this cloning feature doesn't transfer files directly between > nodes). The workspace will be zipped on the node then transfered to > master then to an other node (so that will generate extra traffic on > our jenkins). > > > 2013/2/15 Prasanna Santhanam <[email protected]>: > > Greetings all, > > > > I work on the Apache CloudStack (incubating) project and would like to > > request for adding a plugin to builds@ jenkins. The Clone Workspace > > plugin would be useful to our project that has a ~500MB git repo. > > Instead of having the repo downloaded each time a job is created it would > > be good to use a clone of the workspace from the build jobs that are > > upstream in the pipeline. > > > > Are there any downsides/concerns to enable this plugin for other > > projects that I might be unaware of? I've been successfully using it > > on our staging jenkins (jenkins.cloudstack.org) for sometime now. > > > > Thanks, > > > > -- > > Prasanna., > > > > -- > Olivier Lamy > Talend: http://coders.talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy
