Skip to content

fix(internal/civisibility): propagate ITR tests-skipping enabled tag#4736

Merged
gh-worker-dd-mergequeue-cf854d[bot] merged 5 commits into
mainfrom
anmarchenko/tests_skipped_tag_propagation
May 12, 2026
Merged

fix(internal/civisibility): propagate ITR tests-skipping enabled tag#4736
gh-worker-dd-mergequeue-cf854d[bot] merged 5 commits into
mainfrom
anmarchenko/tests_skipped_tag_propagation

Conversation

@anmarchenko

Copy link
Copy Markdown
Member

What does this PR do?

Propagates the CI Visibility test.itr.tests_skipping.enabled tag from the Go test session to module, suite, and test spans.

The tag was already written on the session span when ITR was enabled. This change keeps that behavior and also adds the same value to the CI tags map after settings are loaded, so future module, suite, and test spans receive the same run-level value through the existing common-tag propagation path.

It also adds regression coverage for the manual API propagation path and extends the gotesting ITR scenario to assert the tag on session, module, suite, and test spans.

Motivation

SDTEST-3761

Suite and test events need to carry the same ITR tests-skipping enabled value as the session event. Without this, downstream CI Visibility consumers can see the session-level setting but not the corresponding suite/test-level tag.

Testing

  • go test ./internal/civisibility/integrations ./internal/civisibility/integrations/gotesting
  • git diff --check

@anmarchenko
anmarchenko requested a review from a team as a code owner May 7, 2026 11:45
@codecov

codecov Bot commented May 7, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 62.40%. Comparing base (0ebb7ee) to head (b2092ca).

Additional details and impacted files
Files with missing lines Coverage Δ
...nal/civisibility/integrations/gotesting/testing.go 58.82% <100.00%> (ø)

... and 449 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@datadog-datadog-prod-us1-2

datadog-datadog-prod-us1-2 Bot commented May 7, 2026

Copy link
Copy Markdown

Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

🎯 Code Coverage (details)
Patch Coverage: 100.00%
Overall Coverage: 61.80% (+4.02%)

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: caf28f5 | Docs | Datadog PR Page | Give us feedback!

@pr-commenter

pr-commenter Bot commented May 7, 2026

Copy link
Copy Markdown

Benchmarks

Benchmark execution time: 2026-05-12 16:23:29

Comparing candidate commit caf28f5 in PR branch anmarchenko/tests_skipped_tag_propagation with baseline commit 5fd6d9c in branch main.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 274 metrics, 1 unstable metrics, 1 flaky benchmarks without significant changes.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

  • 🟩 = significantly better candidate vs. baseline
  • 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

Known flaky benchmarks

These benchmarks are marked as flaky and will not trigger a failure. Modify FLAKY_BENCHMARKS_REGEX to control which benchmarks are marked as flaky.

Known flaky benchmarks without significant changes:

  • scenario:BenchmarkOTLPTraceWriterFlush

@anmarchenko

Copy link
Copy Markdown
Member Author

E2E Test Report: SUCCESS ✅

Tested by: Shepherd Agent (autonomous QA for Datadog Test Optimization)

Test Environment

  • Method: Local testing with gin playground (Go HTTP framework, ~702 tests, 37 suites, 6 modules)
  • Branch: anmarchenko/tests_skipped_tag_propagation
  • Revision tested: 66c42459a1cd8ef91d6f77d56502f61b27686f9b
  • Backend: Local mockdog with itr-enabled scenario (itr_enabled: true, tests_skipping: true, code_coverage: true)

Results

test.itr.tests_skipping.enabled=true is now present on every span level (previously only on session):

Span level Total spans With tag = true
sessions 6 6 (100%)
modules 6 6 (100%)
suites 37 37 (100%)
tests 702 702 (100%)
Check Status
test.itr.tests_skipping.enabled propagated to module spans
test.itr.tests_skipping.enabled propagated to suite spans
test.itr.tests_skipping.enabled propagated to test spans
Session span retains test.itr.tests_skipping.enabled (no regression)
Total event count matches gin baseline (1043) — no regression
Backend flow intact: settings → skippable → citestcycle
Payloads still gzipped

Test Methodology

  1. Ran the gin playground against local mockdog with the itr-enabled scenario:
    ./bin/crook run gin --dep dd-trace-go=anmarchenko/tests_skipped_tag_propagation --scenario itr-enabled --debug
    
  2. Used --dep dd-trace-go=anmarchenko/tests_skipped_tag_propagation to inject the PR branch via go get.
  3. Inspected the recorded spans with bin/query-spans, counting how many spans at each level carried test.itr.tests_skipping.enabled and verifying the value was true everywhere.
  4. Cross-checked against the gin baseline (1043 events) to confirm no event-production regressions.

Verdict

The fix works as intended — test.itr.tests_skipping.enabled is now propagated from the session through the common-tag propagation path to every module, suite, and test span when ITR is enabled.


This E2E test was performed by Shepherd - autonomous QA agent for Datadog Test Optimization

@anmarchenko
anmarchenko requested a review from tonyredondo May 12, 2026 06:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants