Re: Reducing redundant build at Travis?

Lars Schneider writes: > ... I started > to work on a patch that moves all TravisCI logic into scripts located > in the `ci` folder. These scripts share a `lib-travisci.sh` for common > functions such as `skip_branch_tip_with_tag ()` executed at the > beginning of

Re: Reducing redundant build at Travis?

> On 21 Jul 2017, at 18:44, Junio C Hamano wrote: > > Lars Schneider writes: > >> To answer your question: I don't see an easy solution to the problem. > > That's OK. Thanks for digging. > > I am wondering if the attached would be acceptable as

Re: Reducing redundant build at Travis?

Lars Schneider writes: > To answer your question: I don't see an easy solution to the problem. That's OK. Thanks for digging. I am wondering if the attached would be acceptable as a minimum impact patch to address this issue. I think I got the "are we building a

Re: Reducing redundant build at Travis?

> On 20 Jul 2017, at 17:16, Junio C Hamano wrote: > > Lars Schneider writes: > >>> On 14 Jul 2017, at 17:32, Jeff King wrote: >>> >>> I don't know if Travis's cache storage is up to that challenge. We could >>> probably build such

Re: Reducing redundant build at Travis?

Lars Schneider writes: >> On 14 Jul 2017, at 17:32, Jeff King 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

Re: Reducing redundant build at Travis?

> On 14 Jul 2017, at 17:32, Jeff King wrote: > > On Fri, Jul 14, 2017 at 07:54:16AM -0700, Junio C Hamano wrote: > >>> 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

Re: Reducing redundant build at Travis?

On Fri, Jul 14, 2017 at 07:54:16AM -0700, Junio C Hamano wrote: > > 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 > >

Re: Reducing redundant build at Travis?

Jeff King 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

Re: Reducing redundant build at Travis?

On Thu, Jul 13, 2017 at 02:53:17PM -0700, Junio C Hamano wrote: > >> Unfortunately, https://travis-ci.org/git/git/builds/ shows that it > >> does not care if it spawned a job to build the tip of 'maint' and > >> another for 'v2.13.3' that point at the same thing. > > > > That is indeed suprising

Re: Reducing redundant build at Travis?

Lars Schneider writes: > On Thu, Jul 13, 2017 at 1:44 AM, Junio C Hamano wrote: >> I usually try to stay as late as possible to finish all the >> integration branches in order before pushing out the result; it is >> more efficient to be able to batch

Re: Reducing redundant build at Travis?

On Thu, Jul 13, 2017 at 1:44 AM, Junio C Hamano wrote: > I usually try to stay as late as possible to finish all the > integration branches in order before pushing out the result; it is > more efficient to be able to batch things (for humans). > > I however noticed that This

Reducing redundant build at Travis?

I usually try to stay as late as possible to finish all the integration branches in order before pushing out the result; it is more efficient to be able to batch things (for humans). I however noticed that This often means we would have multiple build jobs at Travis for branches and builds on