Reduce wait time for test job to run as soon as their needed build job is finished

[bric3]

What Does This Do

Narrows selected GitLab tests-stage jobs from needs: [ build_tests ] to needs:parallel:matrix entries that point at the matching build_tests matrix row.

This covers the base, profiling, instrumentation, latest-dependencyinstrumentation, smoke, and muzzle jobs that have a build matrix counterpart. Jobs without a direct counterpart keep the inherited default dependency behavior.

Motivation

Test jobs were only started when all tests have been built. Allowing to run test jobs sooner reduces the feedback loop.

Technically a needs entry that references a parallel matrix job waits for every generated job in that matrix by default.

Using needs:parallel:matrix lets each mapped test job wait only for the build row it actually needs.

Relevant GitLab docs:

• https://docs.gitlab.com/ci/yaml/#needsparallelmatrix
• https://docs.gitlab.com/ci/jobs/job_control/#specify-a-parallelized-job-using-needs-with-multiple-parallelized-jobs

Additional Notes

Later, we'll run on GitLab 18.6 or later, matrix expressions could reduce the static repetition here in a future cleanup. In particular, $[[ matrix.IDENTIFIER ]] can express 1:1 dependencies between parallel matrix jobs at pipeline creation time, if the downstream job matrix carries the same selector identifiers.

Docs: https://docs.gitlab.com/ci/yaml/matrix_expressions/

[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

Startup Time

Scenario	This PR	master	Change
insecure-bank / iast	13,927 ms	13,924 ms	+0.0%
insecure-bank / tracing	12,823 ms	12,954 ms	-1.0%
petclinic / appsec	16,725 ms	16,557 ms	+1.0%
petclinic / iast	16,677 ms	16,740 ms	-0.4%
petclinic / profiling	16,511 ms	16,433 ms	+0.5%
petclinic / tracing	15,949 ms	15,909 ms	+0.3%

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

[AlexeyKuznetsov-DD]

Cool!
Maybe worth to add some comments explaining that feature?
left minor comments about unused anchors...

[bric3]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-05-28 08:41:00 UTC ℹ️ Start processing command /merge

---

2026-05-28 08:41:12 UTC ℹ️ MergeQueue: waiting for PR to be ready

This pull request is not mergeable according to GitHub. Common reasons include pending required checks, missing approvals, or merge conflicts — but it could also be blocked by other repository rules or settings.
It will be added to the queue as soon as checks pass and/or get approvals. View in MergeQueue UI.
Note: if you pushed new commits since the last approval, you may need additional approval.
You can remove it from the waiting list with /remove command.

---

2026-05-28 09:03:17 UTC ℹ️ MergeQueue: merge request added to the queue

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

---

2026-05-28 10:18:48 UTC ℹ️ MergeQueue: This merge request was merged