I've been eyeballing Mark's impressive work on the build system in
Gradle. Hoss asked a
numer of questions that relate to tests and I feel I should address
them, even if some poorly. Here it comes, inlined with Hoss's
questions.
> If tests_jvms is a lucene/solr specific property, that needs to be in a users
> "multi-project" "~/.gradle" file
Yeah... I'm not at all a fan of modifying the global gradle settings
file. While it may be ok for settings that only apply to Lucene (if
prefixed) there are other things like enabling or disabling the daemon
which should be a matter of project-local settings. Ideally, I'd like
to see something like:
checkout/gradle-defaults.properties [versioned]
checkout/gradle-local.properties [developer-tweaks, not versioned]
but short of declaring a custom "user home" for gradle (-g switch) I
don't see how this can be achieved. Perhaps the initial checkout could
not carry gradle.properties at all and the build would require an
initial setup via Mark's "defaultUserConfig". This could then write
(unversioned!) gradle.properties with the selected defaults within the
checkout folder (so there'd be no need to tweak the global file).
People can then tweak it to their liking or call defaultUserConfig
with appropriate options again to overwrite the changes.
> How do we get "reproduce with" type output (by default) when a test fails?
This should be doable -- we do it from Ant after all. You can pass
properties to gradle via "-P" so this can be used in the same way we
pass them to ant. In fact, it already works:
gradlew :lucene:lucene-core:test --tests TestDemo -Ptests.seed=deadbeef
> For that matter, how do we get *all* of the logging from failed tests to be
> written to stdout/stderr when a test fail?
There probably is an API in gradle to do this. I know Ryan wrote a
runner for Elastic a long time ago so there may be even code to look
at. I agree it is quite important to get this to work, especially for
CI logs.
> What's the plan as far as things like "ant beast", "-Dtests.dups",
> "-Dtests.iters" & "-Dtests.jvms" ?
Reiteration (tests.iters) is part of the test runner so it'd already
work if that property was passed to it (via -P). It isn't at the
moment -- I'll work on it.
As for tests.dups and tests.jvms this will have to be emulated somehow
at Gradle level. Don't know how though. I'm sure there'll be ways --
this is essentially a programming language.
> ("-Dtests.jvms=1" is important for figuring out if/how the execution of one
> test might polute static variables in the JVM
I don't think it'll work even if you have one JVM unless Gradle test
runner's order is deterministic... which I'm not sure it is, even with
a single JVM that runs the tests.
> is there a simple option to prevent gradle from using curses even though it
> detects it's being run in a tty?
You can pass --console=plain to gradle, use -Dorg.gradle.console=plain
or specify this property in any other way (via environment variable,
etc.). See here:
https://docs.gradle.org/current/userguide/build_environment.html
Dawid
On Mon, Sep 16, 2019 at 8: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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
