metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Miklavcic <michael.miklav...@gmail.com>
Subject Re: [DISCUSS] Build RPM/DEBs in Travis?
Date Wed, 22 May 2019 14:28:04 GMT
I think Justin was just giving rationale, not suggesting we shouldn't make
the improvements. I think at one point we also had some ambiguity about
whether or how Docker was going to run in Travis, but I believe some folks
have found a path through that? I agree with you both - let's get this
added to Travis. Good suggestion, Nick. +1.

On Wed, May 22, 2019 at 7:53 AM Nick Allen <nick@nickallen.org> wrote:

> Yes, running up Full Dev is a manual verification that is required.  And as
> a manual verification sometimes that will get missed.  And in this specific
> case, tt does seem a bit silly that the addition of a parser should require
> the contributor to run up Full Dev.
>
> That being said, anything we can do to reduce the amount of manual
> verification that is required is a good thing.  We should be pushing
> ourselves to an end state where no manual verification is required for any
> Metron PR.  I think building the RPMs/DEBs as part of the Travis build is
> at least a small step in the right direction.
>
>
> On Wed, May 22, 2019 at 9:34 AM Justin Leet <justinjleet@gmail.com> wrote:
>
> > Theoretically, we didn't need to before there were both RPMs and DEBs
> since
> > running dev up (which necessitates building those) is part of the build
> > process. Since they've been split apart, I agree we probably should be
> > building them, because nobody is going to run both unless they
> specifically
> > done something they'd expect to affect both.
> >
> > On Wed, May 22, 2019 at 9:30 AM Nick Allen <nick@nickallen.org> wrote:
> >
> > > In light of issues like this
> https://github.com/apache/metron/pull/1419,
> > > has anyone looked into building our RPMs and DEBs in Travis?  This is a
> > > very common and easy mistake to make and our CI builds really should be
> > > able to catch this.
> > >
> >
>

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