Add scenario duplicates for dd-trace-java with forced v1 protocol - #7439
Add scenario duplicates for dd-trace-java with forced v1 protocol#7439AlexeyKuznetsov-DD wants to merge 17 commits into
dd-trace-java with forced v1 protocol#7439Conversation
|
|
🎉 All green!🧪 All tests passed 🔄 Datadog auto-retried 1 job - 1 passed on retry 🔗 Commit SHA: 5c7252b | Docs | Datadog PR Page | Give us feedback! |
3b4ecdc to
ef40c24
Compare
dd-trace-java with forced v1 protocol.
dd-trace-java with forced v1 protocol.dd-trace-java with forced v1 protocol
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7381053080
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| _duplicate_jobs( | ||
| jobs, | ||
| weblog_names=("spring-boot-jetty",), | ||
| name_suffix="_v1", | ||
| weblog_env={"DD_TRACE_AGENT_PROTOCOL_VERSION": "1.0"}, |
There was a problem hiding this comment.
Preserve duplicated jobs in GitLab rendering
For any GitLab Java prod run containing spring-boot-jetty, utils/ci/gitlab/build_pipeline.py flattens these jobs to (weblog, scenario, build_required) and discards both weblog_instance and weblog_env. The original and _v1 copies therefore produce identical top-level keys in system-tests.yml.j2 (for example, system_tests_run_java_DEFAULT_spring-boot-jetty twice), while neither job receives DD_TRACE_AGENT_PROTOCOL_VERSION; the generated pipeline may reject or collapse the duplicate definitions and cannot provide the intended v1 coverage. Preserve the suffix and environment in the GitLab renderer, or avoid generating these copies for that backend.
Useful? React with 👍 / 👎.
| if library == "java" and ci_environment == "prod": | ||
| jobs.extend( | ||
| _duplicate_jobs( |
There was a problem hiding this comment.
Reserve matrix capacity before adding v1 jobs
When splitting already consumes maximum_parallel_jobs, extending the list afterward violates that limit. With the current Java end-to-end scenarios, desired_execution_time=1 and maximum_parallel_jobs=256 return 273 serialized jobs because 17 Jetty shards are duplicated after capping; .github/workflows/system-tests.yml feeds the entire list directly into one matrix, exceeding its configured capacity. Reserve slots for duplicates before splitting or reapply the cap after duplication.
Useful? React with 👍 / 👎.
cbeauchesne
left a comment
There was a problem hiding this comment.
I've made few RC, but the biggest one is on how the duplication is performed.
For maintainability and complexity reasons, we think that the duplication should be handled inside the CI orchestrator, but directly in workflow call.
It'll be too complex to explain in the PR, let's discuss all of that tomorrow in our meeting with @nccatoni.
| default: false | ||
| required: false | ||
| type: boolean | ||
| weblog_env: |
There was a problem hiding this comment.
Rename this into force_v1_traces (type boolean, default false).
This option should be populated threw different system-tests layers, and handled into WeblogInfra.configure
| SYSTEM_TESTS_FORCE_EXECUTE: ${{ inputs.force_execute }} | ||
| SYSTEM_TESTS_DEV_MODE: ${{ inputs._system_tests_dev_mode }} | ||
| SYSTEM_TESTS_WEBLOG: ${{ inputs.weblog }} | ||
| SYSTEM_TESTS_WEBLOG_ENV: ${{ inputs.weblog_env }} |
There was a problem hiding this comment.
| SYSTEM_TESTS_WEBLOG_ENV: ${{ inputs.weblog_env }} | |
| SYSTEM_TESTS_FORCE_v1_TRACES: ${{ inputs.force_v1_traces }} |
| {% endfor %} | ||
| {% for variant, scenario, build_required in scenario_pairs %} | ||
| system_tests_run_{{library}}_{{scenario}}_{{variant}}: | ||
| {% for job in scenario_jobs %} |
There was a problem hiding this comment.
You can remove any gitlab stuff, we'll handle it.
Motivation
Validate the v1 trace intake protocol in
dd-trace-javabefore it becomes the tracer default, while retaining the existing v0.x jobs as a baseline. The coverage should exercise the complete scenario set for a selected weblog instead.Changes
_duplicate_jobsutility that selects weblogs by name and duplicates every generated job/shard for them, preserving each job's complete scenario list.spring-boot-jettyjobs, suffix their instances with_v1, and setDD_TRACE_AGENT_PROTOCOL_VERSION=1.0on the weblog container.spring-boot-jettyjobs unchanged so the same coverage continues to run with v0.x.DD_APM_ENABLE_V1_TRACE_ENDPOINTsetting fromAPM_TRACING_EFFICIENT_PAYLOAD; current Agents expose the v1 endpoint by default.Impact
The additional v1 coverage is limited to Java prod jobs for
spring-boot-jetty. Java dev, other Java weblogs, and all other tracers keep their existing matrices unchanged. Because selection happens by weblog name, every current or futurespring-boot-jettyshard is duplicated automatically.Validation
_v1Java prodspring-boot-jettyjobs../run.sh TEST_THE_TEST tests/test_the_test/test_ci_orchestrator.py tests/test_the_test/test_docker_scenario.py::test_load_environment_overrides tests/test_the_test/test_build_pipeline.py tests/test_the_test/test_gitlab_pipeline_structure.py— 23 passed.spring-boot-jettyjob with an equivalent_v1duplicate carrying the protocol override.Workflow
🚀 Once your PR is reviewed and the CI green, you can merge it!
🛟 #apm-shared-testing 🛟
Reviewer checklist
tests/ormanifests/is modified ? I have the approval from R&P teambuild-XXX-imagelabel is present