[ABLD-310] Add --enable_bazel flag to cws-instrumentation.build - #55553
[ABLD-310] Add --enable_bazel flag to cws-instrumentation.build#55553aiuto wants to merge 4 commits into
Conversation
## What this change does Adds an opt-in `enable_bazel` parameter to the `cws-instrumentation.build` invoke task. When set, the task builds via `bazel build //cmd/cws-instrumentation:cws-instrumentation` and copies the resulting binary into place instead of calling `go_build()`. Defaults to False, so existing behavior is unchanged. Also adds the `build_go_binary_with_bazel` helper to `tasks/libs/build/bazel.py`, which runs the bazel build and copies the binary from `bazel-bin` to the expected bin path. ## Motivation Omnibus deprecation: progressively moving `dda inv <x>.build` tasks that omnibus calls onto Bazel-built binaries, one binary at a time, behind an opt-in flag. ## How did you validate this - `dda inv -- -e cws-instrumentation.build --enable-bazel` invokes `bazel build //cmd/cws-instrumentation:cws-instrumentation` as expected. - `dda inv -- -e cws-instrumentation.build` (no flag) still takes the legacy `go_build()` path. - Confirmed the Bazel target itself builds successfully when cross-compiled to Linux (`bazel build //cmd/cws-instrumentation:cws-instrumentation --platforms=//bazel/platforms:linux_arm64`); on macOS, both the legacy and Bazel paths fail identically since `cws-instrumentation` is a Linux-only binary with no darwin build tags and the invoke task does not configure cross-compilation, which is a pre-existing limitation unrelated to this change. - `dda inv linter.python` passes. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
There was a problem hiding this comment.
AI review by Codex (OpenAI) - workflow run
Patch is incorrect because the Bazel path silently ignores behavior-affecting build options supported by this task.
| if enable_bazel: | ||
| build_go_binary_with_bazel("//cmd/cws-instrumentation:cws-instrumentation", BIN_PATH) |
There was a problem hiding this comment.
The early return bypasses every existing build option. In particular, injector_only=True no longer applies the cws_instrumentation_injector_only tag, and arch_suffix=True writes to BIN_PATH instead of the suffixed path expected by callers. Either forward equivalent Bazel flags/output selection or reject unsupported combinations explicitly.
…itioning targets ## What this change does Resolves the built binary's output path via `bazel cquery --output=files` instead of `bazel info bazel-bin` + a hand-built `<package>/<name>_/<name>` path. Some go_binary targets (e.g. ones with custom gotags) build under a Starlark configuration transition, which places their outputs in a `<platform>-ST-<hash>` bazel-out subdirectory that the plain bazel-bin symlink does not point to, so the original approach threw FileNotFoundError for those targets. ## Motivation Omnibus deprecation ## How did you validate this Confirmed `bazel cquery --output=files //cmd/cws-instrumentation:cws-instrumentation` resolves the correct output path. cws-instrumentation itself doesn't trigger a transition so this is a preventive fix carried over from the otel-agent PR, which did hit the bug.
Files inventory check summaryFile checks results against ancestor 6ec84e5e: Results for datadog-agent_7.84.0~devel.git.557.0a9a274.pipeline.133833390-1_amd64.deb:No change detected Results for datadog-iot-agent_7.84.0~devel.git.557.0a9a274.pipeline.133833390-1_amd64.deb:No change detected |
Static quality checks✅ Please find below the results from static quality gates Successful checksInfo
25 successful checks with minimal change (< 2 KiB)
|
Regression DetectorRegression Detector ResultsMetrics dashboard Baseline: 6ec84e5 Optimization Goals: ✅ No significant changes detected
|
| perf | experiment | goal | Δ mean % | Δ mean % CI | trials | links |
|---|---|---|---|---|---|---|
| ➖ | dsd_uds_10mb_3k_timestamped_contexts_cpu | % cpu utilization | +0.50 | [+0.24, +0.75] | 1 | Logs |
| ➖ | quality_gate_metrics_logs | memory utilization | +0.49 | [+0.25, +0.72] | 1 | Logs bounds checks dashboard |
| ➖ | quality_gate_idle_all_features | memory utilization | +0.34 | [+0.31, +0.38] | 1 | Logs bounds checks dashboard |
| ➖ | quality_gate_security_mean_fs_load | memory utilization | +0.02 | [-0.01, +0.06] | 1 | Logs bounds checks dashboard |
| ➖ | quality_gate_idle | memory utilization | -0.07 | [-0.11, -0.03] | 1 | Logs bounds checks dashboard |
| ➖ | quality_gate_security_idle | memory utilization | -0.40 | [-0.44, -0.35] | 1 | Logs bounds checks dashboard |
| ➖ | quality_gate_private_action_runner | memory utilization | -0.40 | [-0.52, -0.27] | 1 | Logs bounds checks dashboard |
| ➖ | quality_gate_security_no_fs_load | memory utilization | -0.52 | [-0.60, -0.44] | 1 | Logs bounds checks dashboard |
| ➖ | dsd_uds_10mb_3k_timestamped_contexts_memory | memory utilization | -0.78 | [-0.99, -0.57] | 1 | Logs |
| ➖ | quality_gate_logs | % cpu utilization | -1.70 | [-2.59, -0.82] | 1 | Logs bounds checks dashboard |
Bounds Checks: ✅ Passed
| perf | experiment | bounds_check_name | replicates_passed | observed_value | links |
|---|---|---|---|---|---|
| ✅ | quality_gate_idle | intake_connections | 10/10 | 4 = 4 | bounds checks dashboard |
| ✅ | quality_gate_idle | memory_usage | 10/10 | 172.21MiB ≤ 179MiB | bounds checks dashboard |
| ✅ | quality_gate_idle | total_bytes_received | 10/10 | 749.80KiB ≤ 819.20KiB | bounds checks dashboard |
| ✅ | quality_gate_idle_all_features | intake_connections | 10/10 | 4 = 4 | bounds checks dashboard |
| ✅ | quality_gate_idle_all_features | memory_usage | 10/10 | 530.65MiB ≤ 537MiB | bounds checks dashboard |
| ✅ | quality_gate_idle_all_features | total_bytes_received | 10/10 | 1.14MiB ≤ 1.25MiB | bounds checks dashboard |
| ✅ | quality_gate_logs | intake_connections | 10/10 | 19 ≤ 40 | bounds checks dashboard |
| ✅ | quality_gate_logs | memory_usage | 10/10 | 213.35MiB ≤ 220MiB | bounds checks dashboard |
| ✅ | quality_gate_logs | missed_bytes | 10/10 | 0B = 0B | bounds checks dashboard |
| ✅ | quality_gate_logs | total_bytes_received | 10/10 | 263.05MiB ≤ 292MiB | bounds checks dashboard |
| ✅ | quality_gate_metrics_logs | cpu_usage | 10/10 | 411.76 ≤ 2000 | bounds checks dashboard |
| ✅ | quality_gate_metrics_logs | intake_connections | 10/10 | 20 ≤ 40 | bounds checks dashboard |
| ✅ | quality_gate_metrics_logs | memory_usage | 10/10 | 421.30MiB ≤ 455MiB | bounds checks dashboard |
| ✅ | quality_gate_metrics_logs | missed_bytes | 10/10 | 0B = 0B | bounds checks dashboard |
| ✅ | quality_gate_metrics_logs | total_bytes_received | 10/10 | 0.94GiB ≤ 1.04GiB | bounds checks dashboard |
| ✅ | quality_gate_private_action_runner | memory_usage | 10/10 | 72.50MiB ≤ 75MiB | bounds checks dashboard |
| ✅ | quality_gate_security_idle | cpu_usage | 10/10 | 28.12 ≤ 100 | bounds checks dashboard |
| ✅ | quality_gate_security_idle | memory_usage | 10/10 | 323.01MiB ≤ 355MiB | bounds checks dashboard |
| ✅ | quality_gate_security_mean_fs_load | cpu_usage | 10/10 | 60.47 ≤ 200 | bounds checks dashboard |
| ✅ | quality_gate_security_mean_fs_load | memory_usage | 10/10 | 303.41MiB ≤ 335MiB | bounds checks dashboard |
| ✅ | quality_gate_security_no_fs_load | cpu_usage | 10/10 | 21.59 ≤ 100 | bounds checks dashboard |
| ✅ | quality_gate_security_no_fs_load | memory_usage | 10/10 | 306.76MiB ≤ 345MiB | bounds checks dashboard |
Explanation
Confidence level: 90.00%
Effect size tolerance: |Δ mean %| ≥ 5.00%
Performance changes are noted in the perf column of each table:
- ✅ = significantly better comparison variant performance
- ❌ = significantly worse comparison variant performance
- ➖ = no significant change in performance
A regression test is an A/B test of target performance in a repeatable rig, where "performance" is measured as "comparison variant minus baseline variant" for an optimization goal (e.g., ingress throughput). Due to intrinsic variability in measuring that goal, we can only estimate its mean value for each experiment; we report uncertainty in that value as a 90.00% confidence interval denoted "Δ mean % CI".
For each experiment, we decide whether a change in performance is a "regression" -- a change worth investigating further -- if all of the following criteria are true:
-
Its estimated |Δ mean %| ≥ 5.00%, indicating the change is big enough to merit a closer look.
-
Its 90.00% confidence interval "Δ mean % CI" does not contain zero, indicating that if our statistical model is accurate, there is at least a 90.00% chance there is a difference in performance between baseline and comparison variants.
-
Its configuration does not mark it "erratic".
CI Pass/Fail Decision
✅ Passed. All Quality Gates passed.
- quality_gate_security_mean_fs_load, bounds check cpu_usage: 10/10 replicas passed. Gate passed.
- quality_gate_security_mean_fs_load, bounds check memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_private_action_runner, bounds check memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_idle_all_features, bounds check intake_connections: 10/10 replicas passed. Gate passed.
- quality_gate_idle_all_features, bounds check memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_idle_all_features, bounds check total_bytes_received: 10/10 replicas passed. Gate passed.
- quality_gate_idle, bounds check intake_connections: 10/10 replicas passed. Gate passed.
- quality_gate_idle, bounds check total_bytes_received: 10/10 replicas passed. Gate passed.
- quality_gate_idle, bounds check memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_security_idle, bounds check memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_security_idle, bounds check cpu_usage: 10/10 replicas passed. Gate passed.
- quality_gate_security_no_fs_load, bounds check memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_security_no_fs_load, bounds check cpu_usage: 10/10 replicas passed. Gate passed.
- quality_gate_logs, bounds check memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_logs, bounds check missed_bytes: 10/10 replicas passed. Gate passed.
- quality_gate_logs, bounds check intake_connections: 10/10 replicas passed. Gate passed.
- quality_gate_logs, bounds check total_bytes_received: 10/10 replicas passed. Gate passed.
- quality_gate_metrics_logs, bounds check intake_connections: 10/10 replicas passed. Gate passed.
- quality_gate_metrics_logs, bounds check memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_metrics_logs, bounds check missed_bytes: 10/10 replicas passed. Gate passed.
- quality_gate_metrics_logs, bounds check total_bytes_received: 10/10 replicas passed. Gate passed.
- quality_gate_metrics_logs, bounds check cpu_usage: 10/10 replicas passed. Gate passed.
Adopts the shared helper's canonical name/shape from the dogstatsd PR. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…vor flag Propagates the shared helper change from the dogstatsd PR (args param passed through to both build and cquery). For tasks with a fips_mode flag, pass --//packages/agent:flavor=fips instead of rejecting fips_mode outright. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
What this change does
Adds an opt-in
enable_bazelparameter to thecws-instrumentation.buildinvoke task. When set, the task builds via
bazel build //cmd/cws-instrumentation:cws-instrumentationand copies theresulting binary into place instead of calling
go_build(). Defaults toFalse, so existing behavior is unchanged.
Also adds the
build_go_binary_with_bazelhelper totasks/libs/build/bazel.py, which runs the bazel build and copies thebinary from
bazel-binto the expected bin path. (This helper is alsobeing added independently in the sibling
loaderPR; whichever mergessecond should dedupe it.)
Motivation
Omnibus deprecation: progressively moving
dda inv <x>.buildtasks thatomnibus calls onto Bazel-built binaries, one binary at a time, behind an
opt-in flag.
How did you validate this
dda inv -- -e cws-instrumentation.build --enable-bazelinvokesbazel build //cmd/cws-instrumentation:cws-instrumentationas expected.dda inv -- -e cws-instrumentation.build(no flag) still takes thelegacy
go_build()path.cross-compiled to Linux (
bazel build //cmd/cws-instrumentation:cws-instrumentation --platforms=//bazel/platforms:linux_arm64); on macOS, both the legacyand Bazel paths fail identically since
cws-instrumentationis aLinux-only binary with no darwin build tags and the invoke task does not
configure cross-compilation, which is a pre-existing limitation
unrelated to this change.
dda inv linter.pythonpasses.