nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Witt <>
Subject Re: [DISCUSS] CI / Travis / Jenkins
Date Tue, 05 Dec 2017 04:31:56 GMT
Great news!  So for the first time in a long time we now have
travis-ci builds passing!

I incorporated Dustin's PR which changed to the -Ddir-only instead of
-P, added Andre's idea of dropping the -quiet flag, and dropped the
number of builds in the config to a single parallel build with contrib
check now that we're seeing those pass with rat/checkstyle.

A couple failed due to test failures and I filed JIRAs to convert
these into integration tests or resolve.

One actually finished as you can see in its raw log but travis seems
to have gotten confused.

Two passed completely.  I think to reduce strain on Travis-CI
infrastructure we should drop two of the environments.

Current it is in .travis.yml

  - USER_LANGUAGE=default USER_REGION=default

I think we should drop it to


If no objections i'll do that soon.  But, good news is the builds are
coming back to life on Travis-CI and will help streamline review
cycles again!


On Mon, Dec 4, 2017 at 8:29 PM, Joe Witt <> wrote:
> nope. will take a look at this tonight though.
> On Dec 4, 2017 8:09 PM, "Andre" <> wrote:
>> Joe & Joey,
>> I believe setting the maven compilation job to noisy - instead of the
>> current quiet setting - should help solving the issue.
>> Have we tried that?
>> Cheers
>> On 5 Dec 2017 6:26 AM, "Joe Witt" <> wrote:
>> I agree this would be extremely nice to get back on track.  The
>> changes made last night/today to the poms do appear to mean that
>> parallel builds with contrib-check are working.  Perhaps that helps us
>> a little with travis (or not).  I have reviewed a couple PRs though
>> recently that did not even compile much less have clean contrib-checks
>> so it is really nice to have Travis being more reliable.  Does anyone
>> have any sense of the current reasons for issues?  When I've looked
>> the errors made no sense at all.
>> On Mon, Dec 4, 2017 at 2:21 PM, Joey Frazee <>
>> wrote:
>> > I’m sure everyone has noticed that Travis CI fails, incorrectly, more
>> than it succeeds, often due to timeouts and not b/c of the incorrectness
>> of
>> a commit or PR.
>> >
>> > This has been discussed previously, but it’s carried on, and become a
>> > low
>> information signal about the PRs, which has two big impacts: (1) it’s
>> ignored by experienced contributors and reviewers, and (2) it’s confusing
>> or misleading to new contributors.
>> >
>> > So, we really need to find a solution. I can think of a few:
>> >
>> > 1. Continue to push on INFRA to setup Jenkins for NiFi and its
>> sub-projects.
>> >
>> > 2. Implement some kind of quick-test profile and shell script that
>> > checks
>> the most important things along with the subdirectories affected by the
>> PR,
>> and continue to use Travis CI.
>> >
>> > 3. Use some other service like Circle CI or Codeship, which probably
>> isn’t quite what ASF wants but it might make the CI more useful (it also
>> might not).
>> >
>> > 4. Find a sponsor to support a more premium tier of Travis CI (or
>> > equiv.)
>> so the build has enough resources to to succeed. This too probably isn’t
>> preferable but I’m sure we can find a precedent.
>> >
>> > I’m partial to pursuing (1) and (2) together because (1) would give us a
>> long term solution and (2) would have some value for local builds (no need
>> to run the full build) as well as making Travis CI tell us something. The
>> first should be pretty low effort. The second will be labor intensive I
>> think — to identify what counts as quick and change the poms — so it can’t
>> be the answer on its own unless we want to wait longer to see Travis CI
>> become informative.
>> >
>> > What do the rest of you think?
>> >
>> > -joey

View raw message