I can get behind logging to a file, but can we see the file as an output of Travis? Sometimes the problem is that it is failing in Travis but not locally or it is a situation that you want to give guidance on a PR but don't want to pull a branch and rerun tests. If we log to a file, I'd like to make sure we can get that file as part of the Travis build.
On Fri, Oct 28, 2016 at 00:42 Otto Fowler <[email protected]> wrote: > 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? > > > > > > > > > > >
