Allow forked test tasks for source sets other than test

[AlexeyKuznetsov-DD]

What Does This Do

Lets a module register a forked-test task for a source set other than test.

gradle/java_no_deps.gradle registered a single hardcoded forkedTest task bound to sourceSets.test. This turns that registration into a reusable helper next to its siblings in gradle/test-suites.gradle, and calls it with 'test' from the same place as before:

ext.addForkedTestTask = { String sourceSetName ->
  def taskName = sourceSetName == 'test' ? 'forkedTest' : "${sourceSetName}ForkedTest"
  return tasks.register(taskName, Test) {
    group = LifecycleBasePlugin.VERIFICATION_GROUP
    useJUnitPlatform()
    testClassesDirs = sourceSets[sourceSetName].output.classesDirs
    classpath = sourceSets[sourceSetName].runtimeClasspath
  }
}

A module with its own suites now opts in with one line:

addTestSuite('baseTest')
addForkedTestTask('baseTest')  // registers 'baseTestForkedTest'

No behaviour changes for any existing module: forkedTest is still registered for every project, with the same name and the same configuration.

Motivation

Modules that do not use the default test source set silently do not run their forked tests.

The convention plugin excludes **/*ForkedTest* from every non-forked Test task, and the only task that runs them was bound to sourceSets.test. A module that keeps its tests in its own suites — for example to compile the same tests against several Scala versions — therefore has no task that runs its *ForkedTest classes at all.

Two modules are in exactly that state today, with forked tests that have never executed:

• dd-java-agent/instrumentation/pekko/pekko-http-1.0 — 6 classes in src/baseTest
• dd-java-agent/instrumentation/netty/netty-3.8 — 2 classes in src/latestDepTest

This PR only provides the mechanism. Switching those modules on is deliberately left out, because their dormant tests do not currently pass — running pekko's surfaces a real NPE in PekkoHttpClientHelpers$PekkoHttpHeaders during Data Streams injection — and each needs its own investigation.

Additional Notes

This PR only adds the helper; enabling it in existing modules will be handled separately.

Validation:

• :internal-api:forkedTest passed 6 tests, confirming the default test source-set behavior is unchanged.
• A temporary Pekko opt-in registered the custom-source-set forked tasks and ran 146 test cases with no failures (86 conditionally skipped). The opt-in was reverted after validation.
• spotlessGroovyGradleCheck passed.

Contributor Checklist

• Format the title according to the contribution guidelines
• Assign the type: and (comp: or inst:) labels in addition to any other useful labels
• Avoid using close, fix, or any linking keywords when referencing an issue
  Use solves instead, and assign the PR milestone to the issue
• Update the CODEOWNERS file on source file addition, migration, or deletion
• Update public documentation with any new configuration flags or behaviors
• Once approved, use merge queue to merge the PR

Jira ticket: [PROJ-IDENT]

🤖 Generated with Claude Code

[datadog-datadog-prod-us1-2]

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 58.79% (-0.01%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 1fb9331 | Docs | View more details | Give us feedback!}

[dd-octo-sts]

🟢 Java Benchmark SLOs — All performance SLOs passed

Suite	Status
Startup	🟢 pass

SLO thresholds are defined here based on automatically generated metrics. A warning is raised when results are within 5% of the threshold.

PR vs. master results

Scenario	Candidate	master	Δ (95% CI of mean)
startup:insecure-bank:iast:Agent	14.74 s	14.73 s	[-0.8%; +1.0%] (no difference)
startup:insecure-bank:tracing:Agent	13.69 s	13.66 s	[-0.6%; +1.0%] (no difference)
startup:petclinic:appsec:Agent	17.56 s	17.25 s	[+0.9%; +2.7%] (maybe worse)
startup:petclinic:iast:Agent	17.41 s	17.58 s	[-1.9%; -0.1%] (maybe better)
startup:petclinic:profiling:Agent	16.79 s	17.35 s	[-7.5%; +1.0%] (no difference)
startup:petclinic:sca:Agent	17.35 s	17.19 s	[-0.2%; +2.0%] (no difference)
startup:petclinic:tracing:Agent	16.49 s	16.76 s	[-2.5%; -0.7%] (maybe better)

Commit: 1fb9331f · CI Pipeline · Benchmarking Platform UI

---

Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion.

[datadog-datadog-prod-us1-2]

More details

The existing task keeps its default source set. Custom tasks use the selected source set and the same fork controls.

Was this helpful? React 👍 or 👎

_{Open Bits AI session}

_{🤖 Datadog Autotest · Commit 1fb9331 · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest}

[AlexeyKuznetsov-DD]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-09-01 23:07:47 UTC ℹ️ Start processing command /merge

---

2026-09-01 23:07:52 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in master is approximately 1h (p90).

---

2026-09-01 23:46:47 UTC ❌ MergeQueue: The build pipeline contains failing jobs for this merge request

Build pipeline has failing jobs for bd9fd67:

• test_inst_latest: [17, 1/6]

⚠️ Do NOT retry failed jobs directly (why?).

What to do next?

• Investigate the failures and when ready, re-add your pull request to the queue!
• If your PR checks are green, try to rebase/merge. It might be because the CI run is a bit old.
• Any question, go check the FAQ.

Details

Since those jobs are not marked as being allowed to fail, the pipeline will most likely fail.
Therefore, and to allow other builds to be processed, this merge request has been rejected and the pipeline got canceled.

[AlexeyKuznetsov-DD]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-09-01 23:47:39 UTC ℹ️ Start processing command /merge

---

2026-09-01 23:47:44 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in master is approximately 1h (p90).

---

2026-09-02 00:35:56 UTC ℹ️ MergeQueue: This merge request was merged