age-
From: Steven A Rowe [mailto:sar...@syr.edu]
Sent: Tuesday, August 28, 2012 3:56 PM
To: dev@lucene.apache.org
Subject: RE: large messages from Jenkins failures
Actually, after discussing with Uwe on #lucene-dev IRC, I'm looking into
another mechanism to reduce the size of email messages:
Created SOLR-3766 for this.
Dawid
On Wed, Aug 29, 2012 at 2:32 AM, Michael McCandless
wrote:
> On Tue, Aug 28, 2012 at 5:42 PM, Chris Hostetter
> wrote:
>
>> If folks are concerned that certian tests fail to frequently to be
>> considered "stable" and included in the main build, then let's:
>>
On Tue, Aug 28, 2012 at 5:42 PM, Chris Hostetter
wrote:
> If folks are concerned that certian tests fail to frequently to be
> considered "stable" and included in the main build, then let's:
>
> 1) slap a special "@UnstableTest" annotation on them
> 2) set up a new jenkins job that *only* runs
> 1) slap a special "@UnstableTest" annotation on them
> 2) set up a new jenkins job that *only* runs these @UnstableTest jobs
> 3) configure this new jenkins job to not send any email
>
> ...seems like that would satisfy everyone right?
I'm all for it. We can rename @BadApple to @Unstable and
: I didn't say that. I said the opposite - that having imperfect tests
: (or rather tests that cannot be fixed for whatever reason) discourages
: from looking at test failures and makes one just unsubscribe from the
: jenkins mails. If this is the case then yes, I think not having a test
: like th
> Imperfect test coverage is better than no test coverage?
> Seems like we could simply disable all of our tests and then be happy
> because they will never fail ;-)
I didn't say that. I said the opposite - that having imperfect tests
(or rather tests that cannot be fixed for whatever reason) disc
On Tue, Aug 28, 2012 at 4:03 PM, Michael McCandless
wrote:
>> Another option is to redirect solr fails to a different mailing list
>> that only those that care about solr development can follow.
>
> I don't think splintering the dev community is healthy.
Well, it seems like some people would pref
On Tue, Aug 28, 2012 at 3:57 PM, Dawid Weiss
wrote:
> I don't agree with you here. I think having two or three failures
> daily from the same test (and typically with the same message) is far
> worse than not having it at all.
Imperfect test coverage is better than no test coverage?
Seems like we
On Tue, Aug 28, 2012 at 3:04 PM, Yonik Seeley wrote:
> On Tue, Aug 28, 2012 at 2:43 PM, Dawid Weiss
> wrote:
>> 2) I think Solr emits a LOT of logging information to the console. I
>> don't know if all of it is really useful -- I doubt it, really.
>>
>> The solutions I see are simple -- disable t
> Another option is to redirect solr fails to a different mailing list
> that only those that care about solr development can follow.
I don't make a distinction between solr and lucene development, call me odd.
I did try to help with those few tests (and I fixed some others) but no luck.
> Tests
d too long message ...]\n\n"
+ content.substring(contentLength - trailingLength);
msg.setText(text, "UTF-8");
}
Steve
-Original Message-
From: ysee...@gmail.com [mailto:ysee...@gmail.com] On Behalf Of Yonik Seeley
Sent: Tuesday, August 28, 2
On Mon, Aug 20, 2012 at 2:22 PM, Dawid Weiss
wrote:
> Oh, one more thing -- if we suppress the console output we would
> absolutely have to keep (at jenkins) multiple tests-report.txt files
> because these always contain full output dumps (regardless of console
> settings). Otherwise we'd suppress
On Tue, Aug 28, 2012 at 2:43 PM, Dawid Weiss
wrote:
> 2) I think Solr emits a LOT of logging information to the console. I
> don't know if all of it is really useful -- I doubt it, really.
>
> The solutions I see are simple -- disable the tests that fail 3-5
> times and we still don't know what ca
> Unfortunately, -Dtests.showOutput=never penalizes all tests that don't have
> megabytes of failure output because some do.
It doesn't penalize them, it says exactly what it does. A "full"
report is always written to disk, including all sysouts -- look at
tests-report.txt if I recall right.
> W
this would be reasonable, I'm willing to (try to) do the work.
Steve
-Original Message-
From: Steven A Rowe [mailto:sar...@syr.edu]
Sent: Monday, August 20, 2012 4:10 PM
To: dev@lucene.apache.org
Subject: RE: large messages from Jenkins failures
+1 to using -Dtests.showOutput=ne
+1 to using -Dtests.showOutput=never for Jenkins jobs. - Steve
-Original Message-
From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid
Weiss
Sent: Monday, August 20, 2012 2:20 PM
To: dev@lucene.apache.org
Subject: Re: large messages from Jenkins failures
This is
Oh, one more thing -- if we suppress the console output we would
absolutely have to keep (at jenkins) multiple tests-report.txt files
because these always contain full output dumps (regardless of console
settings). Otherwise we'd suppress potentially important info.
Dawid
On Mon, Aug 20, 2012 at
This is partially aggregated by solr failure logs (the output for
successful suites is not emitted to the console). As for myself I
don't look at those e-mails directly, I typicall click on the jenkins
link to see the full output. Alternatively we could suppress the
console output for failures too
18 matches
Mail list logo
