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 < [email protected]> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
