- 
                Notifications
    You must be signed in to change notification settings 
- Fork 15
run tracing integration tests single threaded #1023
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
run tracing integration tests single threaded #1023
Conversation
| BenchmarksComparisonBenchmark execution time: 2025-04-15 12:14:51 Comparing candidate commit 9350442 in PR branch  Found 0 performance improvements and 0 performance regressions! Performance is the same for 52 metrics, 2 unstable metrics. CandidateCandidate benchmark detailsGroup 1
 
 
 Group 2
 
 
 Group 3
 
 
 Group 4
 
 
 Group 5
 
 
 Group 6
 
 
 Group 7
 
 
 Group 8
 
 
 Group 9
 
 
 Group 10
 
 
 Group 11
 
 
 Group 12
 
 
 Group 13
 
 
 BaselineOmitted due to size. | 
| Codecov ReportAll modified and coverable lines are covered by tests ✅ 
 Additional details and impacted files@@            Coverage Diff             @@
##             main    #1023      +/-   ##
==========================================
+ Coverage   71.53%   71.55%   +0.01%     
==========================================
  Files         339      339              
  Lines       50693    50693              
==========================================
+ Hits        36264    36274      +10     
+ Misses      14429    14419      -10     
 🚀 New features to boost your workflow:
 | 
| Artifact Size Benchmark Reportaarch64-alpine-linux-musl
 aarch64-unknown-linux-gnu
 libdatadog-x64-windows
 libdatadog-x86-windows
 x86_64-alpine-linux-musl
 x86_64-unknown-linux-gnu
 | 
This is a temporary stopgap while we investigate some flaky integration tests on CI. There is something up with running docker in docker on GH runners that leads to occasional network connection issues that causes tests that call the datadog test agent to be flaky.
fce5f41    to
    9350442      
    Compare
  
    There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would make sense decorate the target tests using serial_test crate? I think we do this at other places too
https://github.com/search?q=repo%3ADataDog%2Flibdatadog+%23%5Bserial%5D&type=code
so we don't end up serializing everything.
| env: | ||
| RUST_BACKTRACE: 1 | ||
| - name: "[${{ steps.rust-version.outputs.version}}] Tracing integration tests: cargo nextest run --workspace --exclude builder --profile ci --verbose -E 'test(tracing_integration_tests::)'" | ||
| - name: "[${{ steps.rust-version.outputs.version}}] Tracing integration tests: cargo nextest run --workspace --exclude builder --profile ci --test-threads=1 --verbose -E 'test(tracing_integration_tests::)'" | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/question
would it slow down the CI?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This step runs only the integration tests, not the entire test suite. It may add less than 10s to the test job. It will be done long before Miri and the build pipelines on Gitlab.
| 
 @ganeshnj - This is hopefully just a temporary solution while we investigate something more permanent. At least right now, we do want to serialize all the tracing integration tests. And we only want this to apply to GH CI, not local tests. I think using the serial crate would apply this to local test runs by default. | 
| I am going to bypass rules and merge. The profiling fuzzer found a bug yesterday, and I haven't had time to address it yet. | 
What does this PR do?
This is a temporary stopgap while we investigate some flaky integration tests on CI. Tracing integration tests spin up a docker container running the apm test agent. In theory, these containers should be isolated. But when the tests are run on a GH runner there are occasional test failures that indicate a network connection issue if multiple containers are running at the same time. We are investigating a proper fix, but in the meantime this should alleviate flaky failures. The runtime of the suite should only increase by a few seconds as there just a handful of integration tests.
Motivation
What inspired you to submit this pull request?
Additional Notes
Anything else we should know when reviewing?
How to test the change?
Describe here in detail how the change can be validated.