You mean Otto thought of this already only 2 years ago? :)
Skimming over that Jira thread, I think we're just looking for a pass/fail
on the RPM/DEB builds at this point. I can't think of a reason why we'd
need to bring Jenkins into it now that we have the ability to run multiple
build sub-jobs
https://issues.apache.org/jira/browse/METRON-885
On May 22, 2019 at 10:43:22, Justin Leet (justinjl...@gmail.com) wrote:
Yep, that's all I was doing. I'm in favor of adding it to Travis.
On Wed, May 22, 2019 at 10:28 AM Michael Miklavcic <
michael.miklav...@gmail.com> wrote:
> I think Justin
Yep, that's all I was doing. I'm in favor of adding it to Travis.
On Wed, May 22, 2019 at 10:28 AM Michael Miklavcic <
michael.miklav...@gmail.com> wrote:
> I think Justin was just giving rationale, not suggesting we shouldn't make
> the improvements. I think at one point we also had some
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
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
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
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.
