Deduplicate GitLab test job templates

[AlexeyKuznetsov-DD]

What Does This Do

• Extracts shared GitLab test-job setup into .test_job_common for AMD64 and ARM64 jobs.
• Deduplicates the test-agent service configuration used by both architectures.
• Keeps ARM64 jobs gated on the AMD64 build job without downloading its platform-specific artifacts.
• Keeps the ARM64 default JVM subset manual on feature branches while retaining the full ARM64 matrix on merge queue and master.

Motivation

The ARM64 test templates duplicated most of the AMD64 Gradle setup, scripts, report collection, artifacts, retries, and test-agent configuration. That duplication made the architectures prone to drifting whenever shared CI setup changed and made rebases unnecessarily conflict-prone.

Sharing the common template keeps both architectures aligned. The AMD64 build gate also avoids spending ARM64 runner capacity on commits that do not compile.

Additional Notes

• ARM64 jobs remain non-blocking while stability data is collected.
• IBM Java 8 remains excluded because no ARM64 image is available; Oracle Java 8 remains excluded because it is too flaky for CI.
• Relevant precedents: #11364, #11470, and #11835.
• Validation: local YAML parsing and git diff --check passed; the repository commit hook completed its Gradle/Spotless checks successfully (6,534 tasks).

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: N/A

[datadog-prod-us1-3]

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 57.94% (-0.02%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: e243804 | Docs | Datadog PR Page | 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.02 s	14.05 s	[-1.0%; +0.4%] (no difference)
startup:insecure-bank:tracing:Agent	12.90 s	13.02 s	[-1.6%; -0.3%] (maybe better)
startup:petclinic:appsec:Agent	16.94 s	16.23 s	[+0.1%; +8.7%] (maybe worse)
startup:petclinic:iast:Agent	16.90 s	16.94 s	[-1.2%; +0.7%] (no difference)
startup:petclinic:profiling:Agent	16.64 s	16.77 s	[-2.0%; +0.5%] (no difference)
startup:petclinic:sca:Agent	16.80 s	16.50 s	[+1.0%; +2.6%] (maybe worse)
startup:petclinic:tracing:Agent	15.72 s	16.10 s	[-6.4%; +1.7%] (no difference)

Commit: e243804b · 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-prod-us1-3]

More details

Expanded job behavior preserves AMD64 and ARM64 architecture contracts, including test-agent checks, coverage composition, JVM exclusions, manual feature-branch rules, and the intended artifact-free ARM64 build gate.

Was this helpful? React 👍 or 👎

_{📊 Validated against 6 scenarios · Open Bits AI session}

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

[bric3]

LGTM, but I'd make the architecture explicit in amd64 jobs, so there's a consistent job naming.

My comments are not exhaustive, so there might be other places where this applies.

[bric3]

suggestion: I'd make the arcvhitecture explicit for amd64

Suggested change

	.test_job:
	.test_job_amd64:

[bric3]

suggestion: I'd make architecture explicit

[bric3]

suggestion: I'd make architecture explicit

[bric3]

suggestion: It might be a good thing to comment why this is needed.

Honestly I didn't dived into why this was needed, I know it disables class data dharing (CDS) which is used to speed up JVM botstrap, that said this mechanism evolved overt JVM releases so I'm not sure what's at play regarding ARM64 in more recent versions.

• I just know that -Xshare:off won;t use that CDS archive.

If issues arose, I wonder if Linux memory pages are at play when running on ARM64, unusually these systems may use 4 KiB, 16 KiB, or 64 KiB memory pages. And I wonder if the CDS archive has some issues with memory alignment on unusual page size, that said I can be completely off-track.

However about the "trade-off", I would mention slightly slower jvm bootstrap, and maybe a tad higher memory use.

[bric3]

thought: It's just a thought, but interestingly, I wonder if the env var can be picked up, by programmatic launches that are using this all over the place, we might be able to drop the if branch on arm64 in the code and always pick the env var.

That said, maybe, this env var need to be more specific? E.g. PLATFORM_JVM_ARGS