Reduce wait time for test job to run as soon as their needed build job is finished#11470
Reduce wait time for test job to run as soon as their needed build job is finished#11470bric3 wants to merge 1 commit into
Conversation
🟢 Java Benchmark SLOs — All performance SLOs passed
PR vs. master resultsStartup Time
Commit: Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion. |
AlexeyKuznetsov-DD
left a comment
There was a problem hiding this comment.
Cool!
Maybe worth to add some comments explaining that feature?
left minor comments about unused anchors...
|
|
||
| test_base: | ||
| extends: .test_job | ||
| needs: &needs_build_tests_base |
There was a problem hiding this comment.
There is no usage of this anchor, do wee need it?
There was a problem hiding this comment.
Unsure, thx I'll take a look at that!
|
|
||
| test_inst_latest: | ||
| extends: .test_job_with_test_agent | ||
| needs: &needs_build_tests_latestdep |
There was a problem hiding this comment.
Same here, not reused.
|
|
||
| test_profiling: | ||
| extends: .test_job | ||
| needs: &needs_build_tests_profiling |
There was a problem hiding this comment.
Not reused too.
What Does This Do
Narrows selected GitLab
tests-stage jobs fromneeds: [ build_tests ]toneeds:parallel:matrixentries that point at the matchingbuild_testsmatrix row.This covers the
base,profiling,instrumentation,latest-dependencyinstrumentation,smoke, andmuzzlejobs 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
needsentry that references a parallel matrix job waits for every generated job in that matrix by default.Using
needs:parallel:matrixlets each mapped test job wait only for the build row it actually needs.Relevant GitLab docs:
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/