Previously only created new TestDefinitions when explicitlyRequestedNames was non-empty,
leaving uniqueTests with potentially incorrect explicitlySpecified values.
Now always map to create new TestDefinitions with explicitlySpecified based on
whether the test name is in explicitlyRequestedNames.
- isExplicitFqn now checks for '...' in addition to '*' and '?'
- Add testOnly com.test... block with assertions (TestSpec should run, TestSpec2 should not)
- Addresses reviewer feedback: patterns like com.test... should not set explicitlySpecified=true
- Define ExplicitlyRequestedNames(names: Seq[String]) extends TestOption
- In processOptions: declare explicitlyRequestedNames, isExplicitFqn, match case
- Fixes actionsProj/Compile compilation failure in CI
- Use ExplicitlyRequestedNames(selected) so explicitlySpecified=true only for
complete FQNs (no * or ?), not patterns (per TaskDef)
- Pass ExplicitlyRequestedNames from Defaults inputTests0
- Scripted test: add testFull block (exclude @DoNotDiscover), keep clean + testOnly block
**Problem**
When the user runs testOnly with an explicit suite name (e.g. testOnly com.example.MySuite),
ScalaTest suites annotated with @DoNotDiscover were not run because sbt always passed
explicitlySpecified=false to the test framework.
**Solution**
In Tests.processOptions, when the user has specified test filters (orderedFilters.nonEmpty),
mark the filtered tests as explicitlySpecified=true with SuiteSelector so frameworks
can run @DoNotDiscover suites when explicitly requested.
- main-actions: set explicitlySpecified and selectors in processOptions for testOnly path
- scripted test: tests/i5609-do-not-discover-testonly (testOnly com.test.TestSpec2)
**Problem**
Forked console currently pulls in full Zinc, which includes JLine.
**Solution**
This implements a lighter-weight, full Java ForkConsoleMain,
which no longer depends on JLine.
**Problem**
1. forked console is missing user code from the classpath.
2. forked console still blocks the server.
**Solution**
1. This includes proper products and classpaths to the console.
2. This also implements client-side run for console.
When a bundle upload to Central Portal fails, the error now displays the HTTP response body instead of just the status code. This provides more useful debugging information, as the response body typically contains detailed error messages from the server.
- Convert class to object with BasicTestSuite
- Use test() syntax instead of 'should ... in'
- Move RecordingLogger and extension to top-level
- Use Scala 3 colon indentation syntax
Co-authored-by: GlobalStar117 <GlobalStar117@users.noreply.github.com>
When a forked test process crashes (e.g., due to UnsupportedClassVersionError),
sbt would hang forever waiting for test results. This happened because
notifyExit only completed the promise with success, regardless of the
exit code.
This fix checks the exit code and fails the promise if the process
exited with a non-zero code, allowing sbt to properly report the failure
and exit.
Fixes#7429
**Problems**
When running forked tests, sbt uses `Runtime.getRuntime().availableProcessors()` to determine the thread pool size, ignoring `concurrentRestrictions`. This is inconsistent with non-forked parallel tests.
**Expectations**
Users should be able to control the number of parallel test threads in forked mode, similar to how `concurrentRestrictions` works for non-forked tests.
**Notes**
Added a new setting `testForkedParallelism` that allows explicit control:
```scala
testForkedParallelism := Some(2) // Use 2 threads
testForkedParallelism := None // Use availableProcessors() (default)
```
Before this change you had to log into the sonatype account and search for the errors there.
(https://central.sonatype.com/publishing/deployments)
This was inconvenient, especially if you don't have the admin access to the account.
**Problem**
test task is typed to unit.
To distinguish test from any other tasks, we want to actually type this to something.
**Solution**
Forward TestResult to the test task.
**Problem**
I'm seeing NPE in some test-related tests like tests/junit:
[info] [error] java.lang.NullPointerException: Null output stream
[info] [error] at java.io.PrintStream.requireNonNull(PrintStream.java:79)
[info] [error] at java.io.PrintStream.<init>(PrintStream.java:151)
[info] [error] at java.io.PrintStream.<init>(PrintStream.java:135)
[info] [error] at sbt.internal.WorkerProxy.inputStream$lzyINIT1(WorkerExchange.scala:69)
[info] [error] at sbt.internal.WorkerProxy.inputStream(WorkerExchange.scala:69)
[info] [error] at sbt.internal.WorkerProxy.println(WorkerExchange.scala:77)
[info] [error] at sbt.ForkTests$.mainTestTask$$anonfun$1(ForkTests.scala:160)
This is likely coming from ProcessBuilder#run not immediately processing the passed in processIO.
**Solution**
This uses Promise to wait for the processIO to be processed.
**Problem**
1. query string wasn't passed in, so sonaRelease wasn't working
2. deployment name should be human readable
**Solution**
This fixes the query string passing by hand-crafting the URL.
This also generates human readable deployment name.
**Problem**
Sonatype is sunsetting HTTP Rest endpoint OSSRH in June 2025.
**Solution**
This implements a built-in publishing mechanism.
Kudos to David Doyle who has spearheaded Sonatype Central support via sonatype-central-client etc.
Eruis2579
eugene yokota
DEBORAH FUNMILOLA OLABOYE
calm
E.G
MkDev11
xuwei-k
Dmitrii Naumenko
Jules Ivanic
Leonidas Spyropoulos
Josh Soref