The git plugin rework discussions mentioned the possibility of including the "---reference <existing-repository>" argument to git clone so the pack files for a single repository could be reused in multiple repositories on the same machine. Then you could clone to a single directory on the slave, and reference that clone rather than copying the pack files to each of the workspace copies. I don't think it has been implemented yet, but the plugin developers may be willing to share their ideas in case they have an even better idea than using the --reference argument to git clone. Mark Waite
>________________________________ > From: Gergely Nagy <gsz...@gmail.com> >To: jenkinsci-users@googlegroups.com >Sent: Tuesday, February 14, 2012 1:23 PM >Subject: git: reduce clones' disk space > > >Hi Jenkins gurus, > > >I have a load of jobs (50+ I think) which clone the same repository, but >different branches, to build/unit/test/functional test stages. > > >Also, it's a special application of the "job splitting pattern" >(https://wiki.jenkins-ci.org/display/JENKINS/Splitting+a+big+job+into+smaller+jobs): > >the tarball that downstream jobs receive is a much smaller than the entire >workspace: it only contains unknown files(git ls-files -oz: the build >artifacts), which is "just" 400m >vs 1.8G. Downstream jobs unpack this on top of a pristine clone to get up to >speed. This is quite fast (most files are there already) and also seems to do >better change tracking. > > >However it costs space - each of the workspace is ~ 4-5G - half of which is >the git clone. >While git has a good reason to clone everything with all the branches, I don't >need that duplicated 50 times on the Jenkins box. >So am wondering if there is a way to optimise this? >I guess, i'd rather have one single full clone, and let jobs have the work >directories (+index?).. > > >Any enlightments/alternative ideas are appreciated. >thanks, >Gergo > > > > > > > >
