Re: Reducing redundant build at Travis?

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> 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[1] 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.