Re: Reducing redundant build at Travis?
- From
Lars Schneider <larsxschneider@gmail.com>
- Date
- Jul 21, 2017, 16:11 UTC
- Message-ID
- <333FEA3F-BB43-4183-ADD1-14E73E668EA3@gmail.com>
- In-Reply-To
- <xmqq4lu7m94h.fsf@gitster.mtv.corp.google.com>
Show 30 quoted lines
> On 20 Jul 2017, at 17:16, Junio C Hamano <gitster@pobox.com> wrote: > > Lars Schneider <larsxschneider@gmail.com> writes: > >>> On 14 Jul 2017, at 17:32, Jeff King <peff@peff.net> wrote: >>> >>> I don't know if Travis's cache storage is up to that challenge. We could >>> probably build such a lock on top of third-party storage, but things are >>> rapidly getting more complex. >> >> I think we shouldn't go there because of the complexity. I reached out >> to TravisCI and asked about the "hash build twice" problem [1]. Unfortunately, >> I got no response, yet. The issue could also be considered a feature as you >> could perform different actions in your TravisCI configuration based on >> the branch name. > > Oh, no doubt that it is a feature, and a very useful one at that. > With that, we can change actions depending on the branch name in > such a way that normally we do our build and test, but when we are > on a branch (not testing a tag) and its tip is tagged, we become > no-op to avoid the cost of testing. That is the feature we exactly > want. > > The question I had, and wanted a help from you, was if there was a > way we can write that "are we on a branch (not testing a tag) and is > its tip tagged?" test only once in .travis.yml, even though we have > quite a many items in the matrix. With the current way .travis.yml > is laid out, without such a facility, we'd need the logic sprinkled > to at the beginning of all "before_install:" or something like that, > which is not quite optimal.
To answer your question: I don't see an easy solution to the problem.
However, maybe it is solvable with a creative usage of "build-stages"? https://blog.travis-ci.com/2017-05-11-introducing-build-stages
Sorry, Lars