I think we should have all the tests log to file verbosely and to console reduced. We can gather verbose logs on fail and have them part of the clean etc. Error messages from integration components that do not result in test failures will still be a problem otherwise. I do not think personally that the Travis visible logs need to show more than what failed.
On October 27, 2016 at 17:05:28, Ryan Merriman ([email protected]) wrote: > 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? > > > > >
