l cases.
>>
>>
>>
>> Uwe
>>
>>
>>
>> -----
>>
>> Uwe Schindler
>>
>> Achterdiek 19, D-28357 Bremen
>>
>> https://www.thetaphi.de
>>
>> eMail: u...@thetaphi.de
>>
>>
>>
>> *From:* Dawid W
.@thetaphi.de
>
>
>
> *From:* Dawid Weiss
> *Sent:* Friday, February 19, 2021 7:52 PM
> *To:* Lucene Dev
> *Subject:* Re: Random disabling of asserts in tests is not working
>
>
>
>
>
> Hi Uwe,
>
>
>
> No, it's not randomized - always runs
of all cases.
Uwe
-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de
From: Dawid Weiss
Sent: Friday, February 19, 2021 7:52 PM
To: Lucene Dev
Subject: Re: Random disabling of asserts in tests is not working
Hi Uwe,
No
Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> https://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Robert Muir
> *Sent:* Friday, February 19, 2021 3:13 PM
> *To:* dev@lucene.apache.org
> *Subj
Muir
Sent: Friday, February 19, 2021 3:13 PM
To: dev@lucene.apache.org
Subject: Re: Random disabling of asserts in tests is not working
I don't think it is enabled (at least in policeman jenkins). perhaps it didn't
work correctly when the build was cutover to gradle. Take a look
I don't think it is enabled (at least in policeman jenkins). perhaps it
didn't work correctly when the build was cutover to gradle. Take a look at
any old build such as
https://jenkins.thetaphi.de/view/Lucene-Solr/job/Lucene-Solr-master-Linux/29491/
. You can see the variables it randomizes right t
I don't argue either way - just stating it's possible to randomize this.
> I think it has a downside: having a bug in an assert is really more of a
> corner case. This is the kind of thing jenkins is for?
>
This may be the reason why it's fixed by default (it is/was in ant too).
On Fri, Feb 19, 2021 at 8:07 AM Robert Muir wrote:
I think it has a downside: having a bug in an assert is really more of a
> corner case. This is the kind of thing jenkins is for?
>
Ahh, that is indeed a really good point. I would want/expect asserts to
always work correctly when running local
I think it has a downside: having a bug in an assert is really more of a
corner case. This is the kind of thing jenkins is for?
Locally it would be nice for the compile-test-debug loop for the asserts to
always be working. Tying it into random seeds is gonna result in tests that
behave in crazy wa
We sure can - you'd have to derive the default option for
tests.asserts from the seed, much like it's done for file encoding:
https://github.com/apache/lucene-solr/blob/master/gradle/testing/randomization.gradle#L94-L97
This has to be done on the build side, not at runtime, because once
the JVM s
Ahh, you are right, Dawid! I thought our test infra had the randomization
of enabling or disabling assertions, but it looks like it is our Jenkins
jobs that contain the randomization.
Could we somehow move the randomness into our test infrastructure? E.g. it
would have helped Gautam (and other d
Run, for example:
gradlew -p lucene testOpts
to see the options available. Notice this one:
tests.asserts= true # Enables or disables assertions mode.
and run your tests with:
gradlew -p lucene -Ptests.asserts=false test
>From IDE level you can disable assertions with -Dtest
FWIW: I don't remember it ever being randomizable -- because it has to be
set as a commandline arg on the JVM. Users have always been able to set
it to either true|false from the ant/gradle command line however (maybe
Mike was thinking of jenkins jobs that randomize it? ... i thought uwe's
j
13 matches
Mail list logo
