This is no reproduce output yet, in my mind that is waiting with the tests
seed work that I started on but needs review and finishing.
tests_jvms is jvms and no user param naming is yet thought out or final
when it comes to modifying the build. I've instead stuck to exposing few
things and expecting them to get exposed as needed.
tests_jvms is basically a default translation from ant, I'm hoping someone
else want's to own what happens here.
bq. how do we get *all* of the logging from failed tests to be written to
stdout/stderr when a test fail?
Most things are pretty easy in Gradle. If you want to do it or want me to
do it, please file a JIRA. If it's not a quick fix for someone, it would be
great to start tracking what each individual thinks is critical in JIRA.
All the test stuff needs review and some tweaks (has not changed sine last
email thread which you may not have caught), last I remember Dawid signed
up for it starting around today (15th) ;) See previous email chain.
bq. What's the plan as far as things like "ant beast"
beast stuff will come later
tests.jvms is tests_jvms :) The other settings along these lines are either
part of the test Runner (not most) or the Ant test launcher from
RandomizedTesting. We will have some form of beasting, but that's almost
last in line in terms of what I'm doing now.
- Mark
On Mon, Sep 16, 2019 at 1:59 PM Chris Hostetter <hossman_luc...@fucit.org>
wrote:
>
> Some misc questions after playing around with gradle on this branch for a
> bit today in no particular order...
>
> : tests_jvms=5
> ...
> : test_jvms is controlled by us and defaults to the number of cores
> detected
> : / 2.
>
> If tests_jvms is a lucene/solr specific property, that needs to
> be in a users "multi-project" "~/.gradle" file ... shouldn't we name it
> namespace it with something like "lucene_solr_test_jvms" to make that
> clear reduce future confusion/collsion? (as i anticipate this wo't be the
> last prop we may need)
>
> How do we get "reproduce with" type output (by default) when a test fails?
>
> For that matter, how do we get *all* of the logging from failed tests to
> be written to stdout/stderr when a test fail? ... this is pretty
> important for making jenkin's console log a good "one stop shop" for
> understanding everything that went wrong in a build.
>
> ("--debug" and "--info" seem to do this, but they write a *TON* more
> gradle specific shit then "ant test" type logging use to produce by
> default, and don't care if the test passes or not ... which would make
> them way too excessively verbose for a jenkins build)
>
> What's the plan as far as things like "ant beast", "-Dtests.dups",
> "-Dtests.iters" & "-Dtests.jvms" ? ... those types of options are all
> pretty critical for diagnosing and troubleshooting failures.
> ("-Dtests.jvms=1" is important for figuring out if/how the execution of
> one test might polute static variables in the JVM that cause a failure in
> a subsequent class in the sane JVM)
>
> is there a simple option to prevent gradle from using curses even though
> it detects it's being run in a tty?
>
>
> -Hoss
> http://www.lucidworks.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
--
- Mark
http://about.me/markrmiller
