Yeah, it'd be a one time thing, but there's no guarantee our builds (including master) actually run after invalidating the caches. Unfortunately, I don't really have time in the immediate future to play around with it a whole lot to find out if it's viable without additional work (e.g. kick off some runs that just ignore the cache).
Keep in mind, the cache is pushed after the script phase, so if we time out and the build is killed, the cache doesn't get pushed. So we can't might not be able to just ignore a failed build to rebuild the cache, it'll could broken until successful cache push. However, the cache push could potentially occur from the other parallel builds (I'm honestly not sure), in which case it might just be one failure. At that point, the integration tests might pick up the cache like normal and the failure doesn't actually matter. It's just something that potentially needs some playing around with. I really don't want to end up with a broken master build on my PR, because again, I don't have time in the immediate future to fix it. If someone else wants to do the work of running that out in their personal fork / Travis, I'd be super appreciative, otherwise it's gonna be a little bit. On Thu, May 23, 2019 at 11:34 AM Otto Fowler <ottobackwa...@gmail.com> wrote: > Yes, that is what I’m proposing, but if we want to try to break things down > to speed them up, we can still do that ;) > > > On May 23, 2019 at 11:28:51, Michael Miklavcic ( > michael.miklav...@gmail.com) > wrote: > > I think we're talking about killing the cache just 1 time for the purpose > of verifying that the https:// repo endpoints will work. It's possible I'm > misunderstanding how we've configured our caches, but it seems like we'd > just need to kick travis 1x after the first failed build that did all the > downloading, and then the cache will have been populated. > > On Wed, May 22, 2019 at 7:21 AM Nick Allen <n...@nickallen.org> wrote: > > > > Justin Leet said > > <https://github.com/apache/metron/pull/1417#issuecomment-494464795> > > [1]: Looking > > at our build times, I'm actually concerned that if we kill the caches our > > builds won't complete. The integration tests take >45 minutes and it's > very > > possible redownloading everything goes over our remaining time. > > > > To recap, our current Travis CI build is composed of multiple jobs. > Travis' > > time limit of 50 minutes > > <https://docs.travis-ci.com/user/customizing-the-build/#build-timeouts> > > [2] > > is per job, rather than the total build time. While our total build time > > is on the order of 2.5 hours, it is only our integration-test job which > is > > coming close to that 50 minute limit. > > > > We could try splitting our integration tests into multiple jobs. Each of > > these would have the opportunity to run in parallel (given whatever > > resources Travis can allocate to us), but more importantly each one has > its > > own 50 minute limit. For example... > > > > - Parser Integration Tests: > > - `time mvn surefire:test@integration-tests -pl > > "metron-platform/metron-parsing/metron-parsing-storm, > > metron-platform/metron-parsing/metron-parsers, > > metron-platform/metron-parsing/metron-parsers-common/"` > > - Enrichment Integration Tests > > - `time mvn surefire:test@integration-tests -pl > > > > > > "metron-platform/metron-enrichment/metron-enrichment-common/,metron-platform/metron-enrichment/metron-enrichment-storm"` > > > - etc, etc > > > > > > We would just need to determine how to logically split the tests up. If > > this sounds reasonable, I've already got a start on a POC. > > > > --- > > [1] https://github.com/apache/metron/pull/1417#issuecomment-494464795 > > [2] > https://docs.travis-ci.com/user/customizing-the-build/#build-timeouts > > >
