Cover top-level entry files in component label rules#5709
Conversation
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.
🎉 All green!❄️ No new flaky tests detected 🎯 Code Coverage (details) 🔗 Commit SHA: 7a10ea6 | Docs | Datadog PR Page | Give us feedback! |
ivoanjo
left a comment
There was a problem hiding this comment.
👍 LGTM, nice catch, spotted a few more
Strech
left a comment
There was a problem hiding this comment.
I know that we also have an AI Guard label now, does it make sense to add it too?
BenchmarksBenchmark execution time: 2026-05-11 12:27:22 Comparing candidate commit 39fb35a in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 45 metrics, 1 unstable metrics.
|
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.
|
Good call — added an |
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.
What does this PR do?
Updates 5 rules in
.github/labeler.ymlso they match the component's top-level entry file (lib/datadog/<thing>.rb) in addition to the directory contents (lib/datadog/<thing>/**).corelib/datadog/core.rbprofilinglib/datadog/profiling.rbappseclib/datadog/appsec.rbtracinglib/datadog/tracing.rbotellib/datadog/opentelemetry.rbMotivation:
actions/labelergloblib/datadog/<thing>/**matches files inside the directory but not the siblinglib/datadog/<thing>.rbentry-point file. A PR that touches only the entry file is not currently auto-labeled.ci-appis unaffected —lib/datadog/ci.rbdoes not exist.debugger(formerlydebugging) is fixed in #5707.Change log entry
None.
How to test the change?
The labeler workflow runs on
pull_requestevents. Editing onlylib/datadog/profiling.rb(or any of the five entry files above) on a future PR should now apply the corresponding component label.