You could use the add "Additional Behaviour" for "Advanced clone option" to a define a reference repository. A reference repository will provide the same data transfer reduction, without the complexity of defining two repositories.
Mark Waite On Wed, Aug 20, 2014 at 4:04 PM, Nicholas Paufler < nicholas.pauf...@goclio.com> wrote: > I believe I have figured out what the problem is. Still trying to find a > reasonable workaround. > > I had two git repositories defined - one of which was a local cache of the > full git repo that got cloned when the slave starts up (referenced as a > file:// repo) and then the actual github repo. It looks like it's somehow > tied up in that, in that it can't determine the revision (possibly because > it may have built a revision newer than what is in the file:// repo) so it > gives up and decides to build it anyway. > > Rationale for the locally cached repo is to to cut down on data transfer. > Due to the number of branches being tested (120+) and the size of the > workspace (1GB) we delete the workspace after the job completes. To save > having to pull the full repo from Github every time a job runs we wanted to > have at least a semi-recent local cache that would mean we'd only need to > transfer the deltas. > > I'm now trying to figure out an alternative that will give the same result. > > Thanks for the help! > > Nicholas > > -- > 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 jenkinsci-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Thanks! Mark Waite -- 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 jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
