Dawid, sorry for the incomplete information (and for hijacking the thread)!
The "no runnable tests" error indeed isn't an issue for the gradle build.
But for ant I just confirmed that on a clean checkout of
`releases/lucene-solr/8.11.0`:
`ant test -Dtests.class='org.apache.solr.search.facet.*'` yie
You didn't really say much about what the failure *looks* like (in terms
of wether you get an assertion failure, if so where, and what the logs say
etc...) but I tried to run this test (with this seed) locally a few times
and skimmed the logs...
what i see is that some form of "time allowed e
> FWIW: the test-suite-level "no runnable tests" errors usually crop up for me
> when specifying tests with wildcard expressions, e.g.:
> `-Dtests.class='org.apache.solr.search.facet.*'` (with `DebugAgg` being the
> culprit in that case). I just ignore these "no runnable tests" errors (though
>
>LUCENE-9660. Perhaps it's worth porting over to Solr too.
+1 to this, I had been wondering about that!
The above explanation of the test suite error messages is great, and
perhaps would be nice to have in "contributing" docs too.
FWIW: the test-suite-level "no runnable tests" errors usually crop
> The test.seed will cause the randomized testing to choose the same
> locale/timezone/encoding/etc so that if you're hitting a bug that only shows
> up with swahili or for the kiribati timezone it will reproduce reliably.
Correct. Some things will be "derived" from this property at build
time (
Interesting! So, I changed my test.seed from 5B595A296E3623CE to
5B595A296E3623CC by changing the last letter from E to C, and reran the test,
and it passed!
Be curious if it fails for anyone else?
The failing seed version was complaining about various timeouts etc in dealing
with the col
I think Tim's failure mentioned below was caused by SOLR-11623, and it existed
between Nov 18th and Nov 20th when it was reverted. See comments in
https://github.com/apache/solr/pull/427
Jan
> 22. nov. 2021 kl. 15:52 skrev Jason Gerlowski :
>
> According to
> (http://fucit.org/solr-jenkins-re
Hey Jan,
Thanks for starting this discussion. My 2 cents:
- 100% agree that RBAC is often a point of confusion for users.
- +1 to the incremental improvements you suggested for 9.0 as long as
there are docs that make it really clear that the security.json's
semantics are changing and users shoul
The test.seed will cause the randomized testing to choose the same
locale/timezone/encoding/etc so that if you're hitting a bug that only
shows up with swahili or for the kiribati timezone it will reproduce
reliably.
This only works if your test is tripped by something influenced by that
seed. Oth
According to
(http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.security.BaseTestRuleBasedAuthorizationPlugin.testAllPermissionDeniesActionsWhenUserIsNotCorrectRole)
the latest spike in failures looks like it starts around Nov 8th.
(Though the way I
Can someone explain how the -Ptest.seed works, and how I use it to figure out
if a bug exists?
I ran the full set of tests, and had this message:
ERROR: The following test(s) have failed:
-
org.apache.solr.handler.component.DistributedQueryComponentCustomSortTest.test
(:solr:core)
Test
11 matches
Mail list logo