If you go to Hoss’ rollups here: http://fucit.org/solr-jenkins-reports/
Click on "Failures rates for the last 24h/7days” then click on one of the tests you’ll get a popup with a link to the output. IDK how long the output is kept around though. > On Jun 2, 2020, at 4:08 AM, Noble Paul <noble.p...@gmail.com> wrote: > > Is there a way to see the failures and their logs? > > On Tue, Jun 2, 2020 at 12:02 AM Erick Erickson <erickerick...@gmail.com> > wrote: >> >> This week is a significant improvement. Short form: >> >> >> Raw fail count by week totals, most recent week first (corresponds to bits): >> Week: 0 had 68 failures >> Week: 1 had 113 failures >> Week: 2 had 103 failures >> Week: 3 had 102 failures >> >> >> ********Failures in Hoss' reports for the last 4 rollups. >> >> There were 273 unannotated tests that failed in Hoss' rollups. Ordered by >> the date I downloaded the rollup file, newest->oldest. See above for the >> dates the files were collected >> These tests were NOT BadApple'd or AwaitsFix'd >> >> Failures in the last 4 reports.. >> Report Pct runs fails test >> 0123 3.1 1601 41 BasicDistributedZkTest.test >> 0123 1.7 1495 28 MultiThreadedOCPTest.test >> 0123 1.0 1587 14 RollingRestartTest.test >> 0123 3.1 1653 55 >> ScheduledTriggerIntegrationTest.testScheduledTrigger >> 0123 1.3 1574 13 SystemCollectionCompatTest.testBackCompat >> 0123 1.6 1571 14 TestPackages.testPluginLoading >> 0123 0.3 1570 7 >> TestQueryingOnDownCollection.testQueryToDownCollectionShouldFailFast >> ******************************************** >> >> =====================SuppressWarnings====================== >> >> In the attached report there’s a new section counting SuppressWarnings. For >> the nonce, ignore it. Eventually, when all the warnings are fixed or >> suppressed, I will be advocating for _not_ introducing new warnings at least >> on Master. To encourage this, I want un-suppressed warnings to become >> compile-time errors. >> >> That’ll tempt people to just add @SuppressWarnings, and I don’t think that’s >> a proper fix, so the BadApple report will flag files that have more >> @SuppressWarnings than they did last week and I’ll complain ;) There’ll be >> exceptions of course... >> >> Yes, that flies counter to the zillion SuppressWarnings I’m putting in the >> code right now, but I’m not about to try to fix on the order of 5,000 >> warnings in our code all at once. that’s where the SuppressWarnings data is >> coming from in the attached report, I expect the counts to increase until we >> get clean compilations. Martin Fowler talks about rewriting working code for >> no good reason being a bad idea in “Refactoring”... >> >> My goal currently is to get the compilations clean, stop getting worse, and >> then we can make things better. Along about 2040, all the code that >> currently has SuppressWarnings will have been rewritten and they’ll all be >> gone... >> >> ================================== >> Full report: >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org > > > > -- > ----------------------------------------------------- > Noble Paul > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
