Conversation
github-actions
Bot
added
documentation
…solr.index.updatelog.dir
…ention These six config files (and one inline test schema) still referenced the old solr.test.* sysprop names while the corresponding test classes had already been switched to setting tests.solr.*, leaving the placeholders unresolved and silently falling back to their XML defaults.
|
note: the props starting with "tests" (e.g. tests.seed) have historically been (only?) ones related to our build randomization infrastructure. When I see a "tests.somethign", I think this is something controllable via a gradle property (not same as a system property). We could expand that... okay... but I suspect you went down this path without knowing the context |
|
meaning, if we do this, we might want to ensure that all "tests" prefixed properties behave uniformly with respect to the gradle propagation/integration. |
Thats an interesting idea, do you whtink that would be valuable? So if you pass it in from gradle, it overrides what is already defined? And we have some sort of good gradle tooling to be smart about |
Yeah, I didn't know that bit of context, thank you. I was assumign it was more like the At the bottom of https://cwiki.apache.org/confluence/spaces/SOLR/pages/287607235/System+property+naming+structure is the various test properties, it's not comphrensive, but it's a lot of them... Do you think this is moving in the right direction, or did I miss on some of these and should roll back? Or, group in different ways? |
2 participants
https://issues.apache.org/jira/browse/:SOLR-18449
Description
Looks like most of our tests are
tests.blahbut you could make an argument we prefersolr.tests?Solution
Sweep thorugh with a pattern of
tests.with booleans ending in.enabled. The only excpetion istests.verbosewhich technically should betests.verbose.enabledbut that is totally werid.Tests
re run existing test.