[
https://issues.apache.org/jira/browse/SOLR-17666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18053360#comment-18053360
]
Jason Gerlowski commented on SOLR-17666:
----------------------------------------
+1
What sounds most exciting here to me, if I understand your proposal above
correctly, is that it'd expose flags that someone could use to tailor a test or
beast run to the specific change they're making.
Obviously committers should still feel compelled to give every change an
"unaltered" test run to allow randomization to flush out issues....but if I'm
considering a beast run to validate a recent PRS or overseer or SSL bugfix,
it'd be awesome to not waste a bunch of iterations on test-runs where the
particular feature I care about is disabled!
> Run all tests with (or without) SSL per build.
> ----------------------------------------------
>
> Key: SOLR-17666
> URL: https://issues.apache.org/jira/browse/SOLR-17666
> Project: Solr
> Issue Type: Test
> Reporter: David Smiley
> Priority: Major
>
> It'd be easier to debug SSL related test failures if the entire build (all
> the tests) run a consistent SSL enabled/disabled choice, and we either have a
> dedicated build or randomly choose this at the start. We'd be able to use
> Develocity tags, thus aiding tracking patterns. A failure of the build would
> also mean the reproducer line would print the SSL enablement, thus clarifying
> if SSL is a possible factor in the test failure (vs not an issue). The choice
> could be determined in gradle and passed only when enabled. When invoking a
> test in an IDE, no longer will people need to familiarize themselves with
> Solr's insistence on SSL secure randomization entropy, unless of course you
> are trying to debug an SSL failure.
> Admittedly, a down-side is that a change that breaks SSL has a higher chance
> of getting merged without a PR validation noticing.
> This approach could lead to simplified test infrastructure relating to this
> mechanism, as SSL doesn't need to be disabled/reset. It just needs to be
> done once statically.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
