I think --stacktrace prints gradle task stack traces and not the stack trace of things like tests. If I'm wrong and it provides additional details that are useful, feel free to add it.
Finally, in this case, the test was getting stuck and waiting forever and the tests stacktrace was never being shown. On Tue, Jul 7, 2020 at 9:09 AM Tyson Hamilton <tyso...@google.com> wrote: > Is there a reason we don't always run with the --stacktrace flag? Having > this enabled all the time could be useful and wouldn't add any additional > output for successful runs (right?). > > On Tue, Jun 30, 2020 at 1:23 PM Luke Cwik <lc...@google.com> wrote: > >> This rabbitmq:test stuckness has been a common pain point for me >> recently. I did some investigation and found one issue with the test and >> also added a class level timeout for the test. Opened up >> https://github.com/apache/beam/pull/12137 >> >> On Tue, Jun 30, 2020 at 11:22 AM Maximilian Michels <m...@apache.org> >> wrote: >> >>> Hi Alex, >>> >>> Fully agree with you that it can be hard to find the cause for a failing >>> build. You basically need to know the exact keyword to grep for. The >>> reason is that Jenkins does not understand all build logs to display the >>> error directly in the UI. >>> >>> I often do the following for large logs: >>> >>> $ curl >>> >>> https://ci-beam.apache.org/job/beam_PreCommit_Java_Commit/12017/consoleText >>> | less >>> >>> Then I can use '/' to search in the log quickly without my browser >>> slowing down. >>> >>> In the linked build log, I searched for ' FAILED': >>> >>> 09:18:26 > Task :sdks:java:io:rabbitmq:test FAILED >>> 09:18:26 >>> 09:18:26 FAILURE: Build failed with an exception. >>> 09:18:26 >>> 09:18:26 * What went wrong: >>> 09:18:26 Execution failed for task ':sdks:java:io:rabbitmq:test'. >>> 09:18:26 > Process 'Gradle Test Executor 110' finished with non-zero >>> exit value 143 >>> 09:18:26 This problem might be caused by incorrect test process >>> configuration. >>> 09:18:26 Please refer to the test execution section in the User >>> Manual at >>> >>> https://docs.gradle.org/5.2.1/userguide/java_testing.html#sec:test_execution >>> >>> Now, it appears that the rabbitmq tests are timing out but I'm not sure >>> the issue if with rabbitmq because I'm also seeing: >>> >>> Build timed out (after 120 minutes). Marking the build as aborted. >>> Build was aborted >>> Recording test results >>> >>> So maybe some other test slowed down the build and when it reached >>> rabbitmq it was killed. That can probably tested by running the build >>> multiple times. >>> >>> -Max >>> >>> On 30.06.20 19:47, Alex Amato wrote: >>> > Often I see the build failing, but on the next page there are no >>> > warnings and no errors. >>> > >>> > Then when you dive into the full log, it slows down the browser and >>> > there is no obvious ctrl-f keyword to find the error ("error" yields >>> > over 100 results, and the error isn't always at the bottom). Is there >>> a >>> > faster/better way to do it? >>> > >>> > There is a log about the build timing out, but I don't really know >>> what >>> > timed out or where to look next. >>> > >>> > Is 120 min a long enough time? Did something recently happen? If so >>> Can >>> > we increase the timeout until we debug the regression? >>> > >>> > https://ci-beam.apache.org/job/beam_PreCommit_Java_Commit/12017/ >>> > >>> > https://issues.apache.org/jira/browse/BEAM-10390 >>> > >>> > Thanks, I would appreciate any ideas :) >>> > Alex >>> >>
