The last buch of fixes seems to have fixed this. The tests passed on a Jenkins that had failing tests earlier. Thanks Steve Rowe for lending the super-powerful machine that runs the entire suite in 8 min!
I've seen about 20 runs on that box and also runs on Policeman Jenkins with no issues related to this test since the last commit so I've also back-ported this to 5x as well. On Tue, May 26, 2015 at 9:19 AM, Chris Hostetter <[email protected]> wrote: > > : Right, as I said, we weren't hitting this issue due to our Kerberos conf. > : file. i.e. the only thing that was different on our machines as compared > to > : everyone else and moving that conf file got the tests to fail for me. It > : now fails fairly consistently without the patch (from SOLR-7468) and has > : been looking good with the patch. > > that smells like the kind of thing that sould have some "assume sanity > checks" built into it. > > Given: > * the test setups a special env before running the test > * the test assumes the specific env will exist > * the user's machine may already have env properties set before running > ant that affect the expected special env > > therefore: before the test does the setup of the special env, it should > sanity check that the users basic env doesn't have any properties that > violate the "basic" situation. > > so, hypothetical example based on what little i understand the > authentication stuff: if the purpose of a test is to prove that some > requests work with (or w/o) kerberos authentication, then before doing any > setup of a "mock" kerberos env (or before setting up a "mock" situation > where no authentication is required), the test should verify that there > isn't already an existing kerberos env. (or if possible: "unset" whatever > env/properties define that env) > > > trivial example of a similar situation is the script engine tests -- > TestBadConfigs.testBogusScriptEngine: the purpose of the test is to > ensure that a solrconfig.xml file that refers to a script engine (by > name) which is not installed on the machine will produce an expeted error > at Solr init. before doing the Solr init, we have an whitebox assume that > asks the JVM directly if a script engine with that name already exists) > > > > -Hoss > http://www.lucidworks.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Anshum Gupta
