metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Leet <justinjl...@gmail.com>
Subject Re: [DISCUSS] Travis CI Build Time Limits
Date Thu, 23 May 2019 15:54:32 GMT
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 <ottobackwards@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.miklavcic@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 <nick@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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message