Re: Reducing redundant build at Travis?

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 14, 2017, 14:54 UTC
Message-ID: <xmqqbmonrrvr.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170714122401.uahk2fzvcjj3nwve@sigill.intra.peff.net>

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).

Show 7 quoted lines

> 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.