Updated SBTRunner improvements for passing arguments to partest #40
Conversation
This splits ConsoleRunner in two: AbstractRunner contains most of the behavior but doesn't assume (or at least less that before...) that we are running from the command line. ConsoleRunner extends it to do the same as before. Now SBTRunner also extends AbstractRunner (instead of AntRunner), to get support for --grep, --update-check, and all other options, for testing an explicit file, and for pretty output. This requires changes on the scala-partest-interface side too (SBTRunner's public API has changed).
Previously there was no way to set the Java options from sbt. While the Scala build script sets `javaOptions` this only affects the JVM which runs the partest launcher, not the actual tests. This commit improves the handling of `javaOpts` in partest and allows setting it from SBTRunner. You can pass a special ‘-Dpartest.java_opts=…’ argument to it which is handled directly in SBTRunner. partest usage from ant and from the command line does not change.
|
I'm not sure what to make of the build status. The previous build failed because of MiMa but the new commit doesn't affect binary compatibility and the build passed. If this needs to be binary compatible, more work is required. I have a patch for the Scala build ready that passes 100% of partest in the sbt build. It depends on this new version of partest (and the corresponding update for scala-partest-interface). |
|
@adriaanm, do you want to review this or assign someone else? |
|
@lrytz, could you take a look, bitte? |
|
bien sûr |
|
LGTM! |
Updated SBTRunner improvements for passing arguments to partest
|
@szeiger if you need help publishing a new version of scala-partest so that you can depend on it from scala/scala, I'm available. there's a slow path and a fast path. the slow path involves publishing to a staging repo only, adding the dependency to scala/scala pointing to the staging repo, verifying that the tests pass, and only then going back and doing the module release for real. the fast path is just, just publish the module and figure YOLO and if you end up having to publish another one after that, oh well. I went through the slow path once on scala-xml, but scala-xml is a project that lots of people use, so there was some value in making sure we didn't put out a release that needed to immediately be replaced. but only a few projects (scala, scala-js, dotty) depend on partest, so perhaps the fast path is fine here — you might see what the rest of the team thinks. |
|
I agree YOLO is just fine for partest. For other modules, I'd say it depends on the size / riskiness of the patch. |
Updated SBTRunner improvements for passing arguments to partest
Updated SBTRunner improvements for passing arguments to partest
This is an updated version of #24 to be used together with scala/scala-partest-interface#5.