Skip to content

Cover top-level entry files in component label rules#5709

Merged
Strech merged 3 commits into
masterfrom
labeler-cover-entry-files
May 12, 2026
Merged

Cover top-level entry files in component label rules#5709
Strech merged 3 commits into
masterfrom
labeler-cover-entry-files

Conversation

@p-datadog
Copy link
Copy Markdown
Member

What does this PR do?

Updates 5 rules in .github/labeler.yml so they match the component's top-level entry file (lib/datadog/<thing>.rb) in addition to the directory contents (lib/datadog/<thing>/**).

Rule Entry file added
core lib/datadog/core.rb
profiling lib/datadog/profiling.rb
appsec lib/datadog/appsec.rb
tracing lib/datadog/tracing.rb
otel lib/datadog/opentelemetry.rb

Motivation:

actions/labeler glob lib/datadog/<thing>/** matches files inside the directory but not the sibling lib/datadog/<thing>.rb entry-point file. A PR that touches only the entry file is not currently auto-labeled.

ci-app is unaffected — lib/datadog/ci.rb does not exist.

debugger (formerly debugging) is fixed in #5707.

Change log entry

None.

How to test the change?

The labeler workflow runs on pull_request events. Editing only lib/datadog/profiling.rb (or any of the five entry files above) on a future PR should now apply the corresponding component label.

The `lib/datadog/<thing>/**` glob does not match the sibling file
`lib/datadog/<thing>.rb`, so a PR that only edits the component's
top-level entry file isn't auto-labeled. Add the entry files
explicitly to the rules for core, profiling, appsec, tracing, and
otel — each has both a directory and a sibling .rb entry file.

`ci-app` is unaffected since `lib/datadog/ci.rb` does not exist.
@p-datadog p-datadog requested a review from a team as a code owner May 7, 2026 21:52
@p-datadog p-datadog added the AI Generated Largely based on code generated by an AI or LLM. This label is the same across all dd-trace-* repos label May 7, 2026
@dd-octo-sts dd-octo-sts Bot added the dev/github Github repository maintenance and automation label May 7, 2026
Copy link
Copy Markdown
Member

@marcotc marcotc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch!

@datadog-datadog-prod-us1-2
Copy link
Copy Markdown

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

Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

🎯 Code Coverage (details)
Patch Coverage: 100.00%
Overall Coverage: 97.15% (+0.01%)

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

@p-datadog p-datadog requested review from a team and mabdinur and removed request for a team May 8, 2026 00:23
Copy link
Copy Markdown
Member

@ivoanjo ivoanjo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 LGTM, nice catch, spotted a few more

Comment thread .github/labeler.yml Outdated
Comment thread .github/labeler.yml
Copy link
Copy Markdown
Member

@Strech Strech left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know that we also have an AI Guard label now, does it make sense to add it too?

@pr-commenter
Copy link
Copy Markdown

pr-commenter Bot commented May 11, 2026

Benchmarks

Benchmark execution time: 2026-05-11 12:27:22

Comparing candidate commit 39fb35a in PR branch labeler-cover-entry-files with baseline commit c05d989 in branch master.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 45 metrics, 1 unstable metrics.

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 ----------------------------------'

Cover changes to lib/datadog/ai_guard.rb and lib/datadog/ai_guard/**
with the existing ai-guard repository label.

Address review comment by @Strech.
@p-datadog
Copy link
Copy Markdown
Member Author

Good call — added an ai-guard rule covering both lib/datadog/ai_guard.rb and lib/datadog/ai_guard/** in the latest commit.

@Strech Strech merged commit 2c48cd7 into master May 12, 2026
309 of 311 checks passed
@Strech Strech deleted the labeler-cover-entry-files branch May 12, 2026 09:17
@dd-octo-sts dd-octo-sts Bot added this to the 2.33.0 milestone May 12, 2026
hayat01sh1da pushed a commit to hayat01sh1da/dd-trace-rb that referenced this pull request May 13, 2026
Background
----------
The test `Datadog::Profiling::Collectors::CpuAndWallTimeWorker#start ...
records Waiting for GVL samples` (spec/datadog/profiling/collectors/
cpu_and_wall_time_worker_spec.rb:466) has been observed to fail
intermittently on macOS — most recently in
https://github.com/DataDog/dd-trace-rb/actions/runs/25679466916/job/75386638334
(macos-15 + Ruby 3.2 on the head of DataDog#5709). #ee58665235 added debug
instrumentation while waiting for DataDog#5664 to land, and this is the first
recurrence post-DataDog#5664.

Root cause
----------
In `handle_gvl_waiting`'s situation-1 branch, the collector emits an
extra cpu/wall sample for the period between the previous sample and
the moment the thread entered "waiting for GVL". That extra sample is
marked `is_gvl_waiting_state=false`; its `state` label is then chosen
by the classifier in `collectors_stack.c`, which tags the sample as
`"had cpu"` whenever `cpu_time_ns > 0`.

Before DataDog#5664, macOS had no per-thread CPU clock and `cpu_time_ns` was
effectively always 0 here, so the extra sample fell through to
`"unknown"` — which the test's `take_while` filter strips as initial
profiler noise. After DataDog#5664, macOS reads CPU time via Mach
`thread_info(THREAD_BASIC_INFO)`, whose granularity is microseconds. A
thread that briefly held the GVL before parking (e.g. the test's
`loop { Thread.pass }` background thread) accrues a single-digit-µs
reading, which then trips `cpu_time_ns > 0` and tags a sample that is
overwhelmingly wall-only as `"had cpu"`.

The failure sample list shows this exactly: the original "initial"
filtered `had cpu` sample (sample 1) and the *mid-stream* `had cpu`
sample that breaks the assertion (sample 7) have the same shape — 4-8 µs
CPU in ~37 ms of wall time — but only the first is absorbed by the test's
filter, so the second pushes waiting/total below the 5% margin.

Fix
---
Set the extra sample's `cpu_time_ns` to 0. The `update_time_since_
previous_sample` call is retained (without using its return value) so the
cpu-time marker still advances — otherwise the subsequent regular sample
would over-count CPU. The cost is that ~single-digit-µs of pre-wait CPU
per GVL-wait entry is no longer attributed to any sample (it was always
this way on macOS pre-DataDog#5664, and is similarly small on Linux). Benefit:
the extra sample now classifies as `"unknown"` again (the same state it
had on macOS for years), which the test treats correctly.

Verification
------------
Not run locally — the failure is macOS arm64 + Ruby 3.2 specific, and the
local environment does not have a working libdatadog bundle. Relying on
macOS CI for validation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

AI Generated Largely based on code generated by an AI or LLM. This label is the same across all dd-trace-* repos dev/github Github repository maintenance and automation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants