Hi,

I don’t fully remember what the setup previously was, but at least for master 
and 8.x it does not automatically enable/disable asserts. We can of course do 
this together with the other settings like GC or compressed OOPs, its just a 
few more lines in the Groovy file.

 

I was also thinking that we have Security Manager enabled/disabled from time to 
time. But recently, I see no randomization for this on Jenkins, unless it’s 
part of the Gradle build.

 

Uwe

 

-----

Uwe Schindler

Achterdiek 19, D-28357 Bremen

https://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Robert Muir <rcm...@gmail.com> 
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 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 there.

 

You can confirm by clicking console->full log and it prints exact gradle 
command that it runs: 
https://jenkins.thetaphi.de/view/Lucene-Solr/job/Lucene-Solr-master-Linux/29491/consoleFull

 

Let's look into it, in a couple weeks or so? 

 

On Fri, Feb 19, 2021 at 8:32 AM Michael McCandless <luc...@mikemccandless.com 
<mailto:luc...@mikemccandless.com> > wrote:

On Fri, Feb 19, 2021 at 8:07 AM Robert Muir <rcm...@gmail.com 
<mailto:rcm...@gmail.com> > 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 tests ... if we randomly disabled them in our 
checkouts it can cause a false sense of security, too soon.

 

OK, I agree, let's leave it as randomization in Jenkins!  How do we know that 
Jenkins job/s are still randomizing assertions?  Who tests the tester?

 

Mike McCandless

http://blog.mikemccandless.com

Reply via email to