nope. will take a look at this tonight though. On Dec 4, 2017 8:09 PM, "Andre" <andre-li...@fucs.org> 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" <joe.w...@gmail.com> 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 <joey.fra...@icloud.com> > 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 >
