Daniel P. Berrange <berra...@redhat.com> writes: > On Tue, Apr 25, 2017 at 04:24:18PM +0100, Alex Bennée wrote: >> >> Daniel P. Berrange <berra...@redhat.com> writes: >> >> > On Tue, Apr 25, 2017 at 03:51:17PM +0100, Peter Maydell wrote: >> >> Hi; a recent travis build failure made me notice that our .travis.yml >> >> config references a preseed tarball from here: >> >> http://people.linaro.org/~alex.bennee/qemu-submodule-git-seed.tar.xz >> >> >> >> I think this is a bit less than ideal -- we should really be hosting >> >> this on qemu.org. Can we arrange to move it? >> > >> > I'm curious how much speed difference there is in seeding the git >> > submodules >> > in this way vs letting git pull down from git.qemu.org directly ? >> >> It was quite high from what I recall, exacerbated by the fact we have >> quite so many submodules. Unfortunately it doesn't seem that easy to go >> back in the history of the tests to find out so I'll have to re-run the >> test: >> >> https://travis-ci.org/stsquad/qemu/builds/225648653 >> >> So roughly 62s without a seed vs 15s with. I presume the seed is also >> cached by Travis's web-caching. > > Wow, yes, that is quite a difference ! > > I wonder if Travis' arbitrary sub-dir caching feature would help us to > the same extent, while avoiding need to manually maintain the preseed. > > https://docs.travis-ci.com/user/caching/ > > It just caches entire content of a given subdir between runs. First time > it would be slow, but presumably fast thereafter, and any time the submodule > gets new updates, those would get cached too
Maybe but I think the cwd of the build (and therefor the git tree) is user and project name dependent, e.g.: PWD=/home/travis/build/stsquad/testcases But we could certainly try. > > Regards, > Daniel -- Alex Bennée
