I definitely agree with Otto that we need to make our build logs less verbose. I think the first step is to get control of the log levels across various components. Are there specific examples of the types of messages we want to suppress? For instance:
org.apache.metron.profiler.integration.ProfilerIntegrationTest - zookeeper and curator log levels are set to INFO org.apache.metron.enrichment.bolt.ThreatIntelJoinBoltTest - expected exceptions are printed out when they should be suppressed (to Dave's point) ... Maybe building a list of examples will be easier after we take a pass at setting all the log levels to ERROR. Ideally we only see the test results and an error if something really did fail. Does that sound like a reasonable approach? Ryan On Wed, Oct 19, 2016 at 7:44 AM, David Lyle <[email protected]> wrote: > Hi Otto, > > Good point. One of the practices I'd like to see is to suppress any > exception/error output in tests when it's expected. > > Thanks! > > -D... > > > On Wed, Oct 19, 2016 at 8:18 AM, Otto Fowler <[email protected]> > wrote: > > > The Metron build logs contain a great deal of information, including a > > large number of warnings / exceptions that do not result in test failures > > but still fill the log. This makes troubleshooting test/build issues > > difficult. For example - the travis ci log for PR #276’s recent failure > > doesn’t even have the final errors because the log is too long. > > > > What are some things that can be done to make the situation better? > > > > > > >
