Re: Reducing redundant build at Travis?
- Date: Fri, 14 Jul 2017 07:54:16 -0700
- From: Junio C Hamano <gitster@xxxxxxxxx>
- Subject: Re: Reducing redundant build at Travis?
Jeff King <peff@xxxxxxxx> writes:
> Right, I think the right solution is some amount of peeling. Recognizing
> that the commit sha1 is the same, or better yet, not bothering to retest
> trees which have already been tested.
Yup, I also have a hack to avoid testing a version that is only
different in insignificant way (e.g. the only difference being
GIT-VERSION-GEN or Documentation/RelNotes/*) from an installed one
in the script I use after each integration attempt I do, which I use
a few times a day (that's "Meta/Dothem" if anybody is interested).
> If we had some kind of persistent storage, we could do a quick:
> The "git test" script uses this strategy with git-notes as the
> storage, and I've found it quite useful. I don't think we can rely on
> git-notes, but I think Travis gives us some storage options. Even just a
> best-effort cache directory would probably be sufficient (this is an
> optimization, after all).
We do seem to use some persistence to order prove tests already, but
I do not think it helps the common case, where my end-of-day push
pushes out 'maint' and 'v2.13.3' at the same time, because the push
is made with "git push --follow-tags $there maint master next pu"
and the new tag happens to be at 'maint'. It would be nice if
Travis runs were sequential, but I often observe that it creates
jobs for these multiple branches and tags pushed at the same time,
and start running a few of them.