Fix serialization error in spotless test-published-artifacts

[bric3]

What Does This Do

This PR updates the CI configuration to address a serialization bug in the Spotless plugin when no files match the defined extension target. It introduces a dedicated Spotless configuration specifically for the test-published-artifacts verification process.

Check test_published_artifacts's spotless early on in spotless job.

Relates to diffplug/spotless#2994

Motivation

The previous shared Spotless configuration triggered a build failure due to an obscure error involving the Greclipse formatter's serialization, which impacted build stability. This change ensures the setup remains robust and avoids such errors.

Additional Notes

This issue is specific to the Greclipse formatter and arises under certain conditions where no matching files exist. The dedicated configuration provides a clear and isolated solution for this scenario.

More precisely, the failure appears o be a thread-safety bug in Spotless. During Gradle's parallel input fingerprinting, ConfigurationCacheHackList.hashCode() serializes each formatter step. FormatterStepSerializationRoundtrip$HackClone.writeObject does a non-atomic check, then populate on its cleaned field, i.e. it publishes cleaned field before assigning the internal state of FormatterStepSerializationRoundtrip. In our case this led to a second thread that can serialize the half-built "clone", this why we see a

Caused by: java.lang.IllegalStateException: If the initializer was null, then one of roundtripStateInternal or equalityStateInternal should be non-null, and neither was
        at com.diffplug.spotless.FormatterStepSerializationRoundtrip.writeObject(FormatterStepSerializationRoundtrip.java:74)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
        at java.base/java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1072)

The issue was probably never trigger before, because Gradle 9.6 improved the speed in that area (fingerprinting).

Given that test_published_artifacts no longer needs a groovy formatter, I chose to avoid applyin the plugin script of dd-trace-java, and applied a tailored (and simple) spotless configuration.

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
• Add your completed PR to the merge queue by commenting /merge. You can also:
  • Customize the commit message associated with the merge with /merge --commit-message "..."
  • Remove your PR from the merge queue with /merge -c
  • Skip all merge queue checks with /merge -f --reason "reason"; please use this judiciously, as some checks do not run at the PR-level (note: the PR still needs to be mergeable, this will only skip the pre-merge build)
  • Get more information in this doc

Jira ticket: [PROJ-IDENT]

[mcculls]

Just a small Q about the added writeMainVersionFile

Maybe also add comment in test-published-dependencies/build.gradle.kts so someone doesn't revert it back to use $sharedConfigDirectory/spotless.gradle (at least until the upstream issue is fixed)

[bric3]

I'll push a quick commit with added comments

[PerfectSlayer]

It looks a bit hacky but we need it for the build stability

[bric3]

It looks a bit hacky but we need it for the build stability

Given the two gradle projects are separate, and I'm inclined to think the two gradle don't have the same need/bar in code style, that is also a sensible choice.

[PerfectSlayer]

that is also a sensible choice.

Yeah, I wonder what's the gradle convention for this kind of tests... 🤔
At some point, we may merge them both if there is a "gradle way" of doing this.

[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.05 s	13.94 s	[+0.1%; +1.6%] (maybe worse)
startup:insecure-bank:tracing:Agent	12.87 s	13.05 s	[-2.0%; -0.7%] (maybe better)
startup:petclinic:appsec:Agent	16.97 s	16.67 s	[+0.8%; +2.7%] (maybe worse)
startup:petclinic:iast:Agent	16.96 s	17.08 s	[-1.6%; +0.3%] (no difference)
startup:petclinic:profiling:Agent	16.84 s	16.90 s	[-1.4%; +0.6%] (no difference)
startup:petclinic:sca:Agent	16.91 s	16.89 s	[-0.9%; +1.1%] (no difference)
startup:petclinic:tracing:Agent	16.00 s	16.30 s	[-2.7%; -0.9%] (maybe better)

Commit: 65d7d51e · 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.

[bric3]

Green