Bump rules_python to 1.9.0 and fix misuses spotted on Windows#48082
Conversation
Files inventory check summaryFile checks results against ancestor 967586c5: Results for datadog-agent_7.79.0~devel.git.29.06fe616.pipeline.103783640-1_amd64.deb:No change detected |
Static quality checks✅ Please find below the results from static quality gates 31 successful checks with minimal change (< 2 KiB)
On-wire sizes (compressed)
|
Regression DetectorRegression Detector ResultsMetrics dashboard Baseline: 20aa50f Optimization Goals: ✅ No significant changes detected
|
| perf | experiment | goal | Δ mean % | Δ mean % CI | trials | links |
|---|---|---|---|---|---|---|
| ➖ | docker_containers_cpu | % cpu utilization | +1.54 | [-1.48, +4.57] | 1 | Logs |
Fine details of change detection per experiment
| perf | experiment | goal | Δ mean % | Δ mean % CI | trials | links |
|---|---|---|---|---|---|---|
| ➖ | docker_containers_cpu | % cpu utilization | +1.54 | [-1.48, +4.57] | 1 | Logs |
| ➖ | quality_gate_metrics_logs | memory utilization | +1.28 | [+1.04, +1.52] | 1 | Logs bounds checks dashboard |
| ➖ | ddot_metrics_sum_delta | memory utilization | +0.47 | [+0.30, +0.63] | 1 | Logs |
| ➖ | quality_gate_idle_all_features | memory utilization | +0.27 | [+0.23, +0.31] | 1 | Logs bounds checks dashboard |
| ➖ | otlp_ingest_metrics | memory utilization | +0.09 | [-0.07, +0.25] | 1 | Logs |
| ➖ | ddot_logs | memory utilization | +0.06 | [-0.00, +0.12] | 1 | Logs |
| ➖ | file_to_blackhole_500ms_latency | egress throughput | +0.04 | [-0.35, +0.43] | 1 | Logs |
| ➖ | ddot_metrics_sum_cumulative | memory utilization | +0.02 | [-0.12, +0.17] | 1 | Logs |
| ➖ | uds_dogstatsd_to_api_v3 | ingress throughput | +0.02 | [-0.18, +0.21] | 1 | Logs |
| ➖ | file_to_blackhole_0ms_latency | egress throughput | +0.01 | [-0.52, +0.54] | 1 | Logs |
| ➖ | tcp_dd_logs_filter_exclude | ingress throughput | +0.01 | [-0.10, +0.12] | 1 | Logs |
| ➖ | uds_dogstatsd_to_api | ingress throughput | -0.01 | [-0.21, +0.20] | 1 | Logs |
| ➖ | file_to_blackhole_100ms_latency | egress throughput | -0.04 | [-0.11, +0.03] | 1 | Logs |
| ➖ | file_to_blackhole_1000ms_latency | egress throughput | -0.04 | [-0.47, +0.39] | 1 | Logs |
| ➖ | ddot_metrics_sum_cumulativetodelta_exporter | memory utilization | -0.10 | [-0.32, +0.13] | 1 | Logs |
| ➖ | ddot_metrics | memory utilization | -0.13 | [-0.30, +0.04] | 1 | Logs |
| ➖ | uds_dogstatsd_20mb_12k_contexts_20_senders | memory utilization | -0.13 | [-0.19, -0.07] | 1 | Logs |
| ➖ | docker_containers_memory | memory utilization | -0.20 | [-0.27, -0.12] | 1 | Logs |
| ➖ | quality_gate_idle | memory utilization | -0.28 | [-0.33, -0.23] | 1 | Logs bounds checks dashboard |
| ➖ | file_tree | memory utilization | -0.29 | [-0.35, -0.23] | 1 | Logs |
| ➖ | otlp_ingest_logs | memory utilization | -0.58 | [-0.68, -0.48] | 1 | Logs |
| ➖ | tcp_syslog_to_blackhole | ingress throughput | -1.17 | [-1.31, -1.03] | 1 | Logs |
| ➖ | quality_gate_logs | % cpu utilization | -1.68 | [-3.28, -0.07] | 1 | Logs bounds checks dashboard |
Bounds Checks: ❌ Failed
| perf | experiment | bounds_check_name | replicates_passed | observed_value | links |
|---|---|---|---|---|---|
| ✅ | docker_containers_cpu | simple_check_run | 10/10 | 702 ≥ 26 | |
| ✅ | docker_containers_memory | memory_usage | 10/10 | 276.10MiB ≤ 370MiB | |
| ✅ | docker_containers_memory | simple_check_run | 10/10 | 592 ≥ 26 | |
| ✅ | file_to_blackhole_0ms_latency | memory_usage | 10/10 | 0.19GiB ≤ 1.20GiB | |
| ✅ | file_to_blackhole_0ms_latency | missed_bytes | 10/10 | 0B = 0B | |
| ✅ | file_to_blackhole_1000ms_latency | memory_usage | 10/10 | 0.23GiB ≤ 1.20GiB | |
| ✅ | file_to_blackhole_1000ms_latency | missed_bytes | 10/10 | 0B = 0B | |
| ✅ | file_to_blackhole_100ms_latency | memory_usage | 10/10 | 0.20GiB ≤ 1.20GiB | |
| ✅ | file_to_blackhole_100ms_latency | missed_bytes | 10/10 | 0B = 0B | |
| ✅ | file_to_blackhole_500ms_latency | memory_usage | 10/10 | 0.22GiB ≤ 1.20GiB | |
| ✅ | file_to_blackhole_500ms_latency | missed_bytes | 10/10 | 0B = 0B | |
| ✅ | quality_gate_idle | intake_connections | 10/10 | 3 = 3 | bounds checks dashboard |
| ❌ | quality_gate_idle | memory_usage | 9/10 | 175.23MiB > 175MiB | bounds checks dashboard |
| ✅ | quality_gate_idle_all_features | intake_connections | 10/10 | 2 ≤ 3 | bounds checks dashboard |
| ✅ | quality_gate_idle_all_features | memory_usage | 10/10 | 491.09MiB ≤ 550MiB | bounds checks dashboard |
| ✅ | quality_gate_logs | intake_connections | 10/10 | 4 ≤ 6 | bounds checks dashboard |
| ✅ | quality_gate_logs | memory_usage | 10/10 | 205.43MiB ≤ 220MiB | bounds checks dashboard |
| ✅ | quality_gate_logs | missed_bytes | 10/10 | 0B = 0B | bounds checks dashboard |
| ✅ | quality_gate_metrics_logs | cpu_usage | 10/10 | 340.91 ≤ 2000 | bounds checks dashboard |
| ✅ | quality_gate_metrics_logs | intake_connections | 10/10 | 3 ≤ 6 | bounds checks dashboard |
| ✅ | quality_gate_metrics_logs | memory_usage | 10/10 | 411.99MiB ≤ 475MiB | bounds checks dashboard |
| ✅ | quality_gate_metrics_logs | missed_bytes | 10/10 | 0B = 0B | 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
❌ Failed. Some Quality Gates were violated.
- quality_gate_metrics_logs, bounds check cpu_usage: 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 intake_connections: 10/10 replicas passed. Gate passed.
- quality_gate_metrics_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 missed_bytes: 10/10 replicas passed. Gate passed.
- quality_gate_logs, bounds check memory_usage: 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 intake_connections: 10/10 replicas passed. Gate passed.
- quality_gate_idle, bounds check memory_usage: 9/10 replicas passed. Failed 1 which is > 0. Gate FAILED.
- quality_gate_idle, bounds check intake_connections: 10/10 replicas passed. Gate passed.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4b2c2f088a
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
rules_python from 1.8.5 to 1.9.0rules_python to 1.9.0 and fix Windows breakage
a6cfbe2 to
744b3fc
Compare
rules_python to 1.9.0 and fix Windows breakagerules_python to 1.9.0 and fix Windows breakages
744b3fc to
b9b74a8
Compare
#48082 (comment): > I am wondering if we still need to set it for linux, then? > I mean, yes, harmless but still empty, no? > So why don't we just drop it unconditionally and leave a TODO > to reintroduce with no select later?
b9b74a8 to
423bcf0
Compare
#48082 (comment): > I am wondering if we still need to set it for linux, then? > I mean, yes, harmless but still empty, no? > So why don't we just drop it unconditionally and leave a TODO > to reintroduce with no select later?
#48082 (comment): > I am a little bit hesitant to drop those. > We dropped openssl binary for non-fips and then, weeks later Delivery > Team reported that some test fails in staging. > Even though, we most probably don't even need openssl binary for > non-fips flavors there is a test somewhere that checks its existence. > I am not sure if there is no similar check for modules and engines
423bcf0 to
7dd5867
Compare
rules_python to 1.9.0 and fix Windows breakagesrules_python to 1.9.0 and fix misuses spotted on Windows
### What does this PR do? Bump rules_python from 1.8.5 to 1.9.0 in isolation, as a prerequisite for bumping rules_foreign_cc to a commit that requires its transitive deps to be up-to-date. Fix Windows breakages in compliance/package_licenses.bzl and deps/openssl.BUILD.bazel exposed by the bump. ### Motivation rules_python 1.9.0 enables runfiles on Windows for py_binary (bazel-contrib/rules_python#3610). Where 1.8.5 pointed RUNFILES_DIR at the build-time runfiles directory, 1.9.0 makes bazel run copy the runfiles into a fresh temp directory. Bazel skips empty directories in that copy. package_licenses unconditionally included the offers_dir tree artifact in pkg_files. ship_source_offer is not declared by any dep, so offers_dir is always empty. On Linux and macOS bazel run uses symlinks, so an empty tree is harmless. On Windows the directory is absent from the temp copy, and pkg_install's copytree call fails with FileNotFoundError. The fix excludes offers_dir on Windows. The problem is still present in the latest rules_pkg main (bazelbuild/rules_pkg#1046 is unrelated). The openssl FIPS build on Windows declares out_data_dirs = ["ssl", "lib/ossl-modules", "lib/engines-3"]. ssl/ is empty because --openssldir is set to an absolute path (C:/Program Files/…) outside the Bazel sandbox, so install_ssldirs writes there and leaves the sandbox copy empty. lib/ossl-modules/ and lib/engines-3/ are not installed on Windows FIPS (the FIPS provider comes from @openssl_fips). The fix drops these from out_data_dirs on Windows FIPS via the existing fips_windows config_setting. ### Describe how you validated your changes Reproduced both failures locally on a Windows VM with rules_python 1.9.0, confirmed both fixes resolve them. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
#48082 (comment): > I am wondering if we still need to set it for linux, then? > I mean, yes, harmless but still empty, no? > So why don't we just drop it unconditionally and leave a TODO > to reintroduce with no select later?
#48082 (comment): > I am a little bit hesitant to drop those. > We dropped openssl binary for non-fips and then, weeks later Delivery > Team reported that some test fails in staging. > Even though, we most probably don't even need openssl binary for > non-fips flavors there is a test somewhere that checks its existence. > I am not sure if there is no similar check for modules and engines
The review comment was based on the incorrect assumption that no dep declares ship_source_offer. In fact, freetds, openscap, attr, acl, libsepol, systemd, gpg-error and gcrypt do — but none of them are in the Windows dep graph. On Windows, offers_dir is therefore always empty. rules_python 1.9.0 makes `bazel run` copy runfiles to a fresh temp dir and skips empty dirs, causing pkg_install to fail with FileNotFoundError. The select() correctly excluded the offers directory on Windows to avoid this. This reverts commit bc7bb87.
7dd5867 to
06fe616
Compare
Depends on #48082. ### Motivation Moving the unreleased tip of main allows to address Bazel 9 related issues instead of patching locally: - bazel-contrib/rules_foreign_cc#1493 - bazel-contrib/rules_foreign_cc#1492 (`CcInfo` and other `Cc*` symbols) Other notable commits since: - bazel-contrib/rules_foreign_cc#1483 - bazel-contrib/rules_foreign_cc#1490 - bazel-contrib/rules_foreign_cc#1496 ### Additional Notes Patches 0002 (bazel-contrib/rules_foreign_cc#1452) and 0003 (bazel-contrib/rules_foreign_cc#1491) are still carried locally as neither has landed upstream yet (but we're working on it). Co-authored-by: regis.desgroppes <regis.desgroppes@datadoghq.com>
### What does this PR do? Add `common:windows --enable_runfiles` to `.bazelrc`. ### Motivation rules_python 1.9.0 (introduced in #48082) transitions every `py_binary` on Windows to `enable_runfiles=true`. With Bazel's default of `enable_runfiles=false` on Windows, this creates a second Bazel configuration, causing `python_win` to be built twice concurrently. `build_python.bat` writes MSBuild intermediate files (`PCbuild/obj/`, `PCbuild/amd64/`, `msbuild.rsp`) into the shared execroot source tree rather than into the action's output directory, so the two concurrent builds race on those files, manifesting as intermittent `pyconfig.h: No such file or directory` errors that disappear when the remote cache is warm. Setting `enable_runfiles=true` globally makes the transition a no-op (same flag value → same configuration hash → one build of `python_win`), eliminating the race. ### Describe how you validated your changes Analysis of a failing CI job log (`PCbuild/obj/*.pdb` locked by another process during CleanAll). ### Additional Notes This is a short-term workaround. The proper fix is to make `build_python.bat` hermetic by redirecting MSBuild's output and intermediate directories to `$(@d)` instead of the execroot source tree.
### What does this PR do? Add `common:windows --enable_runfiles` to `.bazelrc`. ### Motivation rules_python 1.9.0 (introduced in #48082) transitions every `py_binary` on Windows to `enable_runfiles=true`. With Bazel's default of `enable_runfiles=false` on Windows, this creates a second Bazel configuration, causing `python_win` to be built twice concurrently. `build_python.bat` writes MSBuild intermediate files (`PCbuild/obj/`, `PCbuild/amd64/`, `msbuild.rsp`) into the shared execroot source tree rather than into the action's output directory, so the two concurrent builds race on those files, manifesting as intermittent `pyconfig.h: No such file or directory` errors that disappear when the remote cache is warm. Setting `enable_runfiles=true` globally makes the transition a no-op (same flag value → same configuration hash → one build of `python_win`), eliminating the race. ### Describe how you validated your changes Analysis of a failing CI job log (`PCbuild/obj/*.pdb` locked by another process during CleanAll). ### Additional Notes This is a short-term workaround. The proper fix is to make `build_python.bat` hermetic by redirecting MSBuild's output and intermediate directories to `$(@d)` instead of the execroot source tree.
### What does this PR do? Add `common:windows --enable_runfiles` to `.bazelrc`. ### Motivation rules_python 1.9.0 (introduced in #48082) transitions every `py_binary` on Windows to `enable_runfiles=true`. With Bazel's default of `enable_runfiles=false` on Windows, this creates a second Bazel configuration, causing `python_win` to be built twice concurrently. `build_python.bat` writes MSBuild intermediate files (`PCbuild/obj/`, `PCbuild/amd64/`, `msbuild.rsp`) into the shared execroot source tree rather than into the action's output directory, so the two concurrent builds race on those files, manifesting as intermittent `pyconfig.h: No such file or directory` errors that disappear when the remote cache is warm. Setting `enable_runfiles=true` globally makes the transition a no-op (same flag value → same configuration hash → one build of `python_win`), eliminating the race. ### Describe how you validated your changes Analysis of a failing CI job log (`PCbuild/obj/*.pdb` locked by another process during CleanAll). ### Additional Notes This is a short-term workaround. The proper fix is to make `build_python.bat` hermetic by redirecting MSBuild's output and intermediate directories to `$(@d)` instead of the execroot source tree.
…tc.) (#48188) ### What does this PR do? Add `common:windows --enable_runfiles` to `.bazelrc`. ### Motivation rules_python 1.9.0 (introduced in #48082) transitions every `py_binary` on Windows to `enable_runfiles=true`. With Bazel's default of `enable_runfiles=false` on Windows, this creates a second Bazel configuration, causing `python_win` to be built twice concurrently. `build_python.bat` writes MSBuild intermediate files (`PCbuild/obj/`, `PCbuild/amd64/`, `msbuild.rsp`) into the shared execroot source tree rather than into the action's output directory, so the two concurrent builds race on those files, manifesting as intermittent `pyconfig.h: No such file or directory` errors that disappear when the cache is warm. See, for instance: https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1528499363 Setting `enable_runfiles=true` globally makes the transition a no-op (same flag value => same configuration hash => one build of `python_win`), eliminating the race. ### Describe how you validated your changes Analysis of a failing CI job log (`PCbuild/obj/*.pdb` locked by another process during CleanAll). ### Additional Notes This is a short-term workaround. The proper fix is to make `build_python.bat` hermetic by redirecting MSBuild's output and intermediate directories to `$(@d)` instead of the execroot source tree. `rules_python` doesn't touch `build_python.bat` directly. The connection is through Bazel's configuration graph: 1. `build_python.bat` is invoked by `python_win` (`run_binary` target) in `deps/cpython.BUILD.bazel`, 2. `python_win` is a dependency of `pkg_install` (via `install_files_win`), 3. `pkg_install` from `rules_pkg` is backed by a `py_binary`, 4. `rules_python` 1.9.0 makes every `py_binary` on Windows transition into a new Bazel configuration (`enable_runfiles=true`), 5. Since `python_win` sits in the dependency graph of that `py_binary`, Bazel now needs it in two configurations: the base one (for tests / other consumers) and the transitioned one (for `pkg_install`), 6. Two configurations => two independent Bazel actions, both calling `build_python.bat` in the same execroot directory => race. Co-authored-by: regis.desgroppes <regis.desgroppes@datadoghq.com>
### What does this PR do? Upgrades the Bazel toolchain from 8.6.0 to 9.0.1. ### Motivation 9.0.1 ships two upstream fixes that directly benefit our build: - bazelbuild/bazel#28606: NPE when `--repo_env` is set to an env var that has no value — contributed by Datadog (Joseph Gette). - bazelbuild/bazel#26842: `DefaultSyscallCache` incorrectly treated `BUILD` files and `build` directories as the same entry on case-insensitive / normalizing filesystems (e.g. Linux container on a macOS host), causing spurious build failures. ### Describe how you validated your changes `bazel test //...` passes. ### Additional Notes Groundwork landed in advance: - #47716: Bump `rules_cc` with explicit loads for Bazel 9 - #47745: Fix `rules_cc` leftovers from #47716 for Bazel 9 - #47982: Add explicit `cc_static_library` import for Bazel 9 - #48016: Add explicit `py_binary` import for Bazel 9 - #48071: Bump `rules_foreign_cc` for Bazel 9 fixes - #48082: Bump `rules_python` to 1.9.0 and fix misuses spotted on Windows - #48183: Fix Python hermetic toolchain check for Bazel 9 - #48186: Disable `repo_contents_cache` when in-workspace for Bazel 9 - #48228: Bump `protobuf` Bazel dep to 34.1
### What does this PR do? Upgrades the Bazel toolchain from 8.6.0 to 9.0.1. ### Motivation 9.0.1 ships two upstream fixes that directly benefit our build: - bazelbuild/bazel#28606: NPE when `--repo_env` is set to an env var that has no value — contributed by Datadog (Joseph Gette). - bazelbuild/bazel#26842: `DefaultSyscallCache` incorrectly treated `BUILD` files and `build` directories as the same entry on case-insensitive / normalizing filesystems (e.g. Linux container on a macOS host), causing spurious build failures. ### Describe how you validated your changes `bazel test //...` passes. ### Additional Notes Groundwork landed in advance: - #47716: Bump `rules_cc` with explicit loads for Bazel 9 - #47745: Fix `rules_cc` leftovers from #47716 for Bazel 9 - #47982: Add explicit `cc_static_library` import for Bazel 9 - #48016: Add explicit `py_binary` import for Bazel 9 - #48071: Bump `rules_foreign_cc` for Bazel 9 fixes - #48082: Bump `rules_python` to 1.9.0 and fix misuses spotted on Windows - #48183: Fix Python hermetic toolchain check for Bazel 9 - #48186: Disable `repo_contents_cache` when in-workspace for Bazel 9 - #48228: Bump `protobuf` Bazel dep to 34.1
### What does this PR do? Upgrade `bazel` from 8.6.0 to 9.0.1. ### Motivation Bazel 9.0.1 ships upstream fixes that directly benefit our build & developer experience: - bazelbuild/bazel#26842: `BUILD` files and `build` directories were incorrectly treated as the same entry on case-insensitive filesystems (e.g., Linux container running on a macOS host), causing spurious build failures (esp. for `rloader` we had to `gazelle`-exclude because of that), - bazelbuild/bazel#27695: a contribution of ours (also available in 8.6.0 as bazelbuild/bazel#28367) - nice to have when sharing a folder between a Linux host and a Windows VM through `virtiofs`, - bazelbuild/bazel#28640: another contribution of ours (@JSGette) - critical because it what preventing us from switching to Bazel 9 (ADMS config). ### Describe how you validated your changes `bazel test //...` passes. ### Additional Notes Groundwork landed in advance: - #47716 - #47745 - #47982 - #48016 - #48071 - #48082 - #48183 - #48186 - #48200 (>= Bazel 9 min) - #48201 (>= Bazel 9 min) - #48228 (>= Bazel 9 min) Co-authored-by: regis.desgroppes <regis.desgroppes@datadoghq.com>
### What does this PR do? Upgrade `bazel` from 8.6.0 to 9.0.1. ### Motivation Bazel 9.0.1 ships upstream fixes that directly benefit our build & developer experience: - bazelbuild/bazel#26842: `BUILD` files and `build` directories were incorrectly treated as the same entry on case-insensitive filesystems (e.g., Linux container running on a macOS host), causing spurious build failures (esp. for `rloader` we had to `gazelle`-exclude because of that), - bazelbuild/bazel#27695: a contribution of ours (also available in 8.6.0 as bazelbuild/bazel#28367) - nice to have when sharing a folder between a Linux host and a Windows VM through `virtiofs`, - bazelbuild/bazel#28640: another contribution of ours (@JSGette) - critical because it what preventing us from switching to Bazel 9 (ADMS config). ### Describe how you validated your changes `bazel test //...` passes. ### Additional Notes Groundwork landed in advance: - #47716 - #47745 - #47982 - #48016 - #48071 - #48082 - #48183 - #48186 - #48200 (>= Bazel 9 min) - #48201 (>= Bazel 9 min) - #48228 (>= Bazel 9 min) Co-authored-by: regis.desgroppes <regis.desgroppes@datadoghq.com>
### What does this PR do? - add `common:windows --enable_runfiles` to `.bazelrc` - widen `bazel:test:windows-amd64` from `//bazel/tests/... //rtloader/...` to `//...` with exclusions for Linux-, eBPF-, and gopatch-only targets ### Motivation rules_python 1.9.0 (#48082) transitions every `py_binary` and `py_test` on Windows from `enable_runfiles=auto` to `enable_runfiles=true`. With Bazel's default (`enable_runfiles=false` on Windows), this creates a second Bazel configuration, causing `python_win` to be built twice concurrently. `build_python.bat` writes MSBuild intermediates to the shared execroot source tree rather than the action's output directory, so both builds race on those files, causing intermittent `pyconfig.h` failures. This is a redo of #48188, which was preemptively reverted (#48207). Pre-setting `--enable_runfiles` makes the transition a no-op, so Bazel sees a single configuration and builds `python_win` once. Two prerequisites are now in place: #48281 provides `PYTHON_FOR_BUILD` to MSBuild, preventing `find_python.bat` from falling back to NuGet and other external sources under `--incompatible_strict_action_env`; #48087 and #48209 trigger Windows CI on `MODULE.bazel*` and `.bazel*` changes respectively, so the widened test surface below will catch regressions before they reach `main`. ### Describe how you validated your changes Local VM and, of course, CI. ### Additional Notes `//pkg/template/...` is excluded on Windows: gopatch v0.4.0 errors on `@@\r` in hunk markers when patch files have CRLF line endings, an unreported upstream bug with no workaround in gopatch itself.
Prior art: 1. #48082 2. #48087 3. #48188 (1st attempt) 4. #48207 5. #48281 6. #48209 ### What does this PR do? This is a redo of #48188 (preemptively reverted by #48207) and therefore merely consists in re-adding `common:windows --enable_runfiles` to `.bazelrc`. ... with lessons learned, thanks to earlier: - #48209 covers the present change to `.bazelrc`, - #48281 prevents `find_python.bat` from falling back to `NuGet` or other non hermetic sources. .... and now a widened `bazel:test:windows-amd64`, evolving from just `//bazel/tests/... //rtloader/...` to `//...` **- except currently failing targets** (for the time being, of course). ### Motivation Summary of #48188: - `rules_python` 1.9.0 (#48082) transitions every `py_binary` and `py_test` on Windows from `enable_runfiles=auto` to `enable_runfiles=true`, - with Bazel's default (`enable_runfiles=false` on Windows), this creates a second Bazel configuration, causing `python_win` to be built twice concurrently, - `build_python.bat` writes `MSBuild` intermediates to the shared execroot source tree rather than the action's output directory, so both builds race on those files, causing [intermittent failures](https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1533753039) (`pyconfig.h` not found, etc.). **Pre-setting `--enable_runfiles` makes the transition a no-op, so Bazel sees a single configuration and builds `python_win` once.** ### Describe how you validated your changes Local VM and, of course, CI. ### Additional Notes For instance, `//pkg/template/...` is excluded on Windows because `gopatch` errors on `@@\r` in hunk markers when patch files have CRLF line endings, which deserves a distinct PR (likely adjusting `.gitattributes`). Co-authored-by: regis.desgroppes <regis.desgroppes@datadoghq.com>
### What does this PR do? Bump `rules_python` from 1.8.5 to 1.9.0 in isolation, as a prerequisite for bumping `rules_foreign_cc` to a commit that requires its transitive deps to be up-to-date (#48071). This requires to fix Windows breakages exposed by the bump: ``` The following shell command exited with status 1: $ bazelisk run --//:install_dir=C:/opt/datadog-agent --//packages/agent:flavor=base -- //packages/install_dir:install Output: (nothing) Error: [...] INFO: Running command line: C:/bzl/bazel/bv4fleb2/execroot/_main/bazel-out/x64_windows-fastbuild-ST-591ff087943d/bin/packages/install_dir/install.exe INFO: Installing to C:/opt/datadog-agent Traceback (most recent call last): [...] File "C:\Users\ContainerAdministrator\AppData\Local\Temp\Bazel.runfiles_heizzvq5\runfiles\rules_python++python+python_3_12_x86_64-pc-windows-msvc\Lib\shutil.py", line 598, in copytree with os.scandir(src) as itr: ^^^^^^^^^^^^^^^ FileNotFoundError: [WinError 3] The system cannot find the path specified: 'C:\\Users\\ContainerAdministrator\\AppData\\Local\\Temp\\Bazel.runfiles_heizzvq5\\runfiles/_main/packages/install_dir/sources' ``` ([example](https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1524102425#L1688)) ``` The following shell command exited with status 1: $ bazelisk run --//packages/agent:flavor=fips -- @openssl//:install --destdir=C:/opt/datadog-agent Output: (nothing) Error: [...] INFO: Running command line: C:/bzl/bazel/bv4fleb2/execroot/_main/bazel-out/x64_windows-fastbuild-ST-591ff087943d/bin/external/+_repo_rules+openssl/install.exe <args omitted> INFO: Installing to C:/opt/datadog-agent Traceback (most recent call last): [...] File "C:\Users\ContainerAdministrator\AppData\Local\Temp\Bazel.runfiles_5r0pk0mf\runfiles\rules_python++python+python_3_12_x86_64-pc-windows-msvc\Lib\shutil.py", line 598, in copytree with os.scandir(src) as itr: ^^^^^^^^^^^^^^^ FileNotFoundError: [WinError 3] The system cannot find the path specified: 'C:\\Users\\ContainerAdministrator\\AppData\\Local\\Temp\\Bazel.runfiles_5r0pk0mf\\runfiles/+_repo_rules+openssl/openssl/ssl' ``` ([example](https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1524399502#L484)) ### Motivation `rules_python` 1.9.0 enables runfiles on Windows (👍) for `py_binary` (bazel-contrib/rules_python#3610) so, where 1.8.5 pointed `RUNFILES_DIR` at the build-time runfiles directory, 1.9.0 makes `bazel run` copy the runfiles into a fresh temp directory **where Bazel would skip empty directories**, logically leading `pkg_install`'s `copytree` to fail with above `FileNotFoundError` cases. Bug (TODOs) surfaced: 1. `package_licenses` unconditionally included the `offers_dir` tree artifact in `pkg_files` but, since **`ship_source_offer` is not declared by any dep (work in progress?), `offers_dir` is always empty**: - on Linux and macOS `bazel run` uses symlinks, so an empty tree is useless but harmless, - on Windows the directory is absent from the temp copy => `FileNotFoundError`. **The fix consists in excluding `offers_dir` on ~Windows~ _all platforms_ until the work is resumed.** 2. the openssl FIPS build on Windows declares `out_data_dirs = ["ssl", "lib/ossl-modules", "lib/engines-3"]`, but `ssl/` is empty because `--openssldir` is set to an absolute path (`C:/Program Files/…`) **outside the Bazel sandbox**, so `install_ssldirs` writes there and leaves the sandbox copy empty => `FileNotFoundError`. **The fix drops `ssl/` from `out_data_dirs` on Windows FIPS** via the existing `fips_windows` config setting. ### Describe how you validated your changes Reproduced the failures locally on a Windows VM with rules_python 1.9.0, confirmed the fixes resolve them. Co-authored-by: regis.desgroppes <regis.desgroppes@datadoghq.com>
Depends on #48082. ### Motivation Moving the unreleased tip of main allows to address Bazel 9 related issues instead of patching locally: - bazel-contrib/rules_foreign_cc#1493 - bazel-contrib/rules_foreign_cc#1492 (`CcInfo` and other `Cc*` symbols) Other notable commits since: - bazel-contrib/rules_foreign_cc#1483 - bazel-contrib/rules_foreign_cc#1490 - bazel-contrib/rules_foreign_cc#1496 ### Additional Notes Patches 0002 (bazel-contrib/rules_foreign_cc#1452) and 0003 (bazel-contrib/rules_foreign_cc#1491) are still carried locally as neither has landed upstream yet (but we're working on it). Co-authored-by: regis.desgroppes <regis.desgroppes@datadoghq.com>
…tc.) (#48188) ### What does this PR do? Add `common:windows --enable_runfiles` to `.bazelrc`. ### Motivation rules_python 1.9.0 (introduced in #48082) transitions every `py_binary` on Windows to `enable_runfiles=true`. With Bazel's default of `enable_runfiles=false` on Windows, this creates a second Bazel configuration, causing `python_win` to be built twice concurrently. `build_python.bat` writes MSBuild intermediate files (`PCbuild/obj/`, `PCbuild/amd64/`, `msbuild.rsp`) into the shared execroot source tree rather than into the action's output directory, so the two concurrent builds race on those files, manifesting as intermittent `pyconfig.h: No such file or directory` errors that disappear when the cache is warm. See, for instance: https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1528499363 Setting `enable_runfiles=true` globally makes the transition a no-op (same flag value => same configuration hash => one build of `python_win`), eliminating the race. ### Describe how you validated your changes Analysis of a failing CI job log (`PCbuild/obj/*.pdb` locked by another process during CleanAll). ### Additional Notes This is a short-term workaround. The proper fix is to make `build_python.bat` hermetic by redirecting MSBuild's output and intermediate directories to `$(@d)` instead of the execroot source tree. `rules_python` doesn't touch `build_python.bat` directly. The connection is through Bazel's configuration graph: 1. `build_python.bat` is invoked by `python_win` (`run_binary` target) in `deps/cpython.BUILD.bazel`, 2. `python_win` is a dependency of `pkg_install` (via `install_files_win`), 3. `pkg_install` from `rules_pkg` is backed by a `py_binary`, 4. `rules_python` 1.9.0 makes every `py_binary` on Windows transition into a new Bazel configuration (`enable_runfiles=true`), 5. Since `python_win` sits in the dependency graph of that `py_binary`, Bazel now needs it in two configurations: the base one (for tests / other consumers) and the transitioned one (for `pkg_install`), 6. Two configurations => two independent Bazel actions, both calling `build_python.bat` in the same execroot directory => race. Co-authored-by: regis.desgroppes <regis.desgroppes@datadoghq.com>
### What does this PR do? Upgrade `bazel` from 8.6.0 to 9.0.1. ### Motivation Bazel 9.0.1 ships upstream fixes that directly benefit our build & developer experience: - bazelbuild/bazel#26842: `BUILD` files and `build` directories were incorrectly treated as the same entry on case-insensitive filesystems (e.g., Linux container running on a macOS host), causing spurious build failures (esp. for `rloader` we had to `gazelle`-exclude because of that), - bazelbuild/bazel#27695: a contribution of ours (also available in 8.6.0 as bazelbuild/bazel#28367) - nice to have when sharing a folder between a Linux host and a Windows VM through `virtiofs`, - bazelbuild/bazel#28640: another contribution of ours (@JSGette) - critical because it what preventing us from switching to Bazel 9 (ADMS config). ### Describe how you validated your changes `bazel test //...` passes. ### Additional Notes Groundwork landed in advance: - #47716 - #47745 - #47982 - #48016 - #48071 - #48082 - #48183 - #48186 - #48200 (>= Bazel 9 min) - #48201 (>= Bazel 9 min) - #48228 (>= Bazel 9 min) Co-authored-by: regis.desgroppes <regis.desgroppes@datadoghq.com>
Prior art: 1. #48082 2. #48087 3. #48188 (1st attempt) 4. #48207 5. #48281 6. #48209 ### What does this PR do? This is a redo of #48188 (preemptively reverted by #48207) and therefore merely consists in re-adding `common:windows --enable_runfiles` to `.bazelrc`. ... with lessons learned, thanks to earlier: - #48209 covers the present change to `.bazelrc`, - #48281 prevents `find_python.bat` from falling back to `NuGet` or other non hermetic sources. .... and now a widened `bazel:test:windows-amd64`, evolving from just `//bazel/tests/... //rtloader/...` to `//...` **- except currently failing targets** (for the time being, of course). ### Motivation Summary of #48188: - `rules_python` 1.9.0 (#48082) transitions every `py_binary` and `py_test` on Windows from `enable_runfiles=auto` to `enable_runfiles=true`, - with Bazel's default (`enable_runfiles=false` on Windows), this creates a second Bazel configuration, causing `python_win` to be built twice concurrently, - `build_python.bat` writes `MSBuild` intermediates to the shared execroot source tree rather than the action's output directory, so both builds race on those files, causing [intermittent failures](https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1533753039) (`pyconfig.h` not found, etc.). **Pre-setting `--enable_runfiles` makes the transition a no-op, so Bazel sees a single configuration and builds `python_win` once.** ### Describe how you validated your changes Local VM and, of course, CI. ### Additional Notes For instance, `//pkg/template/...` is excluded on Windows because `gopatch` errors on `@@\r` in hunk markers when patch files have CRLF line endings, which deserves a distinct PR (likely adjusting `.gitattributes`). Co-authored-by: regis.desgroppes <regis.desgroppes@datadoghq.com>
### What does this PR do? Bump `rules_python` from 1.8.5 to 1.9.0 in isolation, as a prerequisite for bumping `rules_foreign_cc` to a commit that requires its transitive deps to be up-to-date (#48071). This requires to fix Windows breakages exposed by the bump: ``` The following shell command exited with status 1: $ bazelisk run --//:install_dir=C:/opt/datadog-agent --//packages/agent:flavor=base -- //packages/install_dir:install Output: (nothing) Error: [...] INFO: Running command line: C:/bzl/bazel/bv4fleb2/execroot/_main/bazel-out/x64_windows-fastbuild-ST-591ff087943d/bin/packages/install_dir/install.exe INFO: Installing to C:/opt/datadog-agent Traceback (most recent call last): [...] File "C:\Users\ContainerAdministrator\AppData\Local\Temp\Bazel.runfiles_heizzvq5\runfiles\rules_python++python+python_3_12_x86_64-pc-windows-msvc\Lib\shutil.py", line 598, in copytree with os.scandir(src) as itr: ^^^^^^^^^^^^^^^ FileNotFoundError: [WinError 3] The system cannot find the path specified: 'C:\\Users\\ContainerAdministrator\\AppData\\Local\\Temp\\Bazel.runfiles_heizzvq5\\runfiles/_main/packages/install_dir/sources' ``` ([example](https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1524102425#L1688)) ``` The following shell command exited with status 1: $ bazelisk run --//packages/agent:flavor=fips -- @openssl//:install --destdir=C:/opt/datadog-agent Output: (nothing) Error: [...] INFO: Running command line: C:/bzl/bazel/bv4fleb2/execroot/_main/bazel-out/x64_windows-fastbuild-ST-591ff087943d/bin/external/+_repo_rules+openssl/install.exe <args omitted> INFO: Installing to C:/opt/datadog-agent Traceback (most recent call last): [...] File "C:\Users\ContainerAdministrator\AppData\Local\Temp\Bazel.runfiles_5r0pk0mf\runfiles\rules_python++python+python_3_12_x86_64-pc-windows-msvc\Lib\shutil.py", line 598, in copytree with os.scandir(src) as itr: ^^^^^^^^^^^^^^^ FileNotFoundError: [WinError 3] The system cannot find the path specified: 'C:\\Users\\ContainerAdministrator\\AppData\\Local\\Temp\\Bazel.runfiles_5r0pk0mf\\runfiles/+_repo_rules+openssl/openssl/ssl' ``` ([example](https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1524399502#L484)) ### Motivation `rules_python` 1.9.0 enables runfiles on Windows (👍) for `py_binary` (bazel-contrib/rules_python#3610) so, where 1.8.5 pointed `RUNFILES_DIR` at the build-time runfiles directory, 1.9.0 makes `bazel run` copy the runfiles into a fresh temp directory **where Bazel would skip empty directories**, logically leading `pkg_install`'s `copytree` to fail with above `FileNotFoundError` cases. Bug (TODOs) surfaced: 1. `package_licenses` unconditionally included the `offers_dir` tree artifact in `pkg_files` but, since **`ship_source_offer` is not declared by any dep (work in progress?), `offers_dir` is always empty**: - on Linux and macOS `bazel run` uses symlinks, so an empty tree is useless but harmless, - on Windows the directory is absent from the temp copy => `FileNotFoundError`. **The fix consists in excluding `offers_dir` on ~Windows~ _all platforms_ until the work is resumed.** 2. the openssl FIPS build on Windows declares `out_data_dirs = ["ssl", "lib/ossl-modules", "lib/engines-3"]`, but `ssl/` is empty because `--openssldir` is set to an absolute path (`C:/Program Files/…`) **outside the Bazel sandbox**, so `install_ssldirs` writes there and leaves the sandbox copy empty => `FileNotFoundError`. **The fix drops `ssl/` from `out_data_dirs` on Windows FIPS** via the existing `fips_windows` config setting. ### Describe how you validated your changes Reproduced the failures locally on a Windows VM with rules_python 1.9.0, confirmed the fixes resolve them. Co-authored-by: regis.desgroppes <regis.desgroppes@datadoghq.com>
Depends on #48082. ### Motivation Moving the unreleased tip of main allows to address Bazel 9 related issues instead of patching locally: - bazel-contrib/rules_foreign_cc#1493 - bazel-contrib/rules_foreign_cc#1492 (`CcInfo` and other `Cc*` symbols) Other notable commits since: - bazel-contrib/rules_foreign_cc#1483 - bazel-contrib/rules_foreign_cc#1490 - bazel-contrib/rules_foreign_cc#1496 ### Additional Notes Patches 0002 (bazel-contrib/rules_foreign_cc#1452) and 0003 (bazel-contrib/rules_foreign_cc#1491) are still carried locally as neither has landed upstream yet (but we're working on it). Co-authored-by: regis.desgroppes <regis.desgroppes@datadoghq.com>
…tc.) (#48188) ### What does this PR do? Add `common:windows --enable_runfiles` to `.bazelrc`. ### Motivation rules_python 1.9.0 (introduced in #48082) transitions every `py_binary` on Windows to `enable_runfiles=true`. With Bazel's default of `enable_runfiles=false` on Windows, this creates a second Bazel configuration, causing `python_win` to be built twice concurrently. `build_python.bat` writes MSBuild intermediate files (`PCbuild/obj/`, `PCbuild/amd64/`, `msbuild.rsp`) into the shared execroot source tree rather than into the action's output directory, so the two concurrent builds race on those files, manifesting as intermittent `pyconfig.h: No such file or directory` errors that disappear when the cache is warm. See, for instance: https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1528499363 Setting `enable_runfiles=true` globally makes the transition a no-op (same flag value => same configuration hash => one build of `python_win`), eliminating the race. ### Describe how you validated your changes Analysis of a failing CI job log (`PCbuild/obj/*.pdb` locked by another process during CleanAll). ### Additional Notes This is a short-term workaround. The proper fix is to make `build_python.bat` hermetic by redirecting MSBuild's output and intermediate directories to `$(@d)` instead of the execroot source tree. `rules_python` doesn't touch `build_python.bat` directly. The connection is through Bazel's configuration graph: 1. `build_python.bat` is invoked by `python_win` (`run_binary` target) in `deps/cpython.BUILD.bazel`, 2. `python_win` is a dependency of `pkg_install` (via `install_files_win`), 3. `pkg_install` from `rules_pkg` is backed by a `py_binary`, 4. `rules_python` 1.9.0 makes every `py_binary` on Windows transition into a new Bazel configuration (`enable_runfiles=true`), 5. Since `python_win` sits in the dependency graph of that `py_binary`, Bazel now needs it in two configurations: the base one (for tests / other consumers) and the transitioned one (for `pkg_install`), 6. Two configurations => two independent Bazel actions, both calling `build_python.bat` in the same execroot directory => race. Co-authored-by: regis.desgroppes <regis.desgroppes@datadoghq.com>
### What does this PR do? Upgrade `bazel` from 8.6.0 to 9.0.1. ### Motivation Bazel 9.0.1 ships upstream fixes that directly benefit our build & developer experience: - bazelbuild/bazel#26842: `BUILD` files and `build` directories were incorrectly treated as the same entry on case-insensitive filesystems (e.g., Linux container running on a macOS host), causing spurious build failures (esp. for `rloader` we had to `gazelle`-exclude because of that), - bazelbuild/bazel#27695: a contribution of ours (also available in 8.6.0 as bazelbuild/bazel#28367) - nice to have when sharing a folder between a Linux host and a Windows VM through `virtiofs`, - bazelbuild/bazel#28640: another contribution of ours (@JSGette) - critical because it what preventing us from switching to Bazel 9 (ADMS config). ### Describe how you validated your changes `bazel test //...` passes. ### Additional Notes Groundwork landed in advance: - #47716 - #47745 - #47982 - #48016 - #48071 - #48082 - #48183 - #48186 - #48200 (>= Bazel 9 min) - #48201 (>= Bazel 9 min) - #48228 (>= Bazel 9 min) Co-authored-by: regis.desgroppes <regis.desgroppes@datadoghq.com>
Prior art: 1. #48082 2. #48087 3. #48188 (1st attempt) 4. #48207 5. #48281 6. #48209 ### What does this PR do? This is a redo of #48188 (preemptively reverted by #48207) and therefore merely consists in re-adding `common:windows --enable_runfiles` to `.bazelrc`. ... with lessons learned, thanks to earlier: - #48209 covers the present change to `.bazelrc`, - #48281 prevents `find_python.bat` from falling back to `NuGet` or other non hermetic sources. .... and now a widened `bazel:test:windows-amd64`, evolving from just `//bazel/tests/... //rtloader/...` to `//...` **- except currently failing targets** (for the time being, of course). ### Motivation Summary of #48188: - `rules_python` 1.9.0 (#48082) transitions every `py_binary` and `py_test` on Windows from `enable_runfiles=auto` to `enable_runfiles=true`, - with Bazel's default (`enable_runfiles=false` on Windows), this creates a second Bazel configuration, causing `python_win` to be built twice concurrently, - `build_python.bat` writes `MSBuild` intermediates to the shared execroot source tree rather than the action's output directory, so both builds race on those files, causing [intermittent failures](https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1533753039) (`pyconfig.h` not found, etc.). **Pre-setting `--enable_runfiles` makes the transition a no-op, so Bazel sees a single configuration and builds `python_win` once.** ### Describe how you validated your changes Local VM and, of course, CI. ### Additional Notes For instance, `//pkg/template/...` is excluded on Windows because `gopatch` errors on `@@\r` in hunk markers when patch files have CRLF line endings, which deserves a distinct PR (likely adjusting `.gitattributes`). Co-authored-by: regis.desgroppes <regis.desgroppes@datadoghq.com>
What does this PR do?
Bump
rules_pythonfrom 1.8.5 to 1.9.0 in isolation, as a prerequisite for bumpingrules_foreign_ccto a commit that requires its transitive deps to be up-to-date (#48071).This requires to fix Windows breakages exposed by the bump:
(example)
(example)
Motivation
rules_python1.9.0 enables runfiles on Windows (👍) forpy_binary(bazel-contrib/rules_python#3610) so, where 1.8.5 pointedRUNFILES_DIRat the build-time runfiles directory, 1.9.0 makesbazel runcopy the runfiles into a fresh temp directory where Bazel would skip empty directories, logically leadingpkg_install'scopytreeto fail with aboveFileNotFoundErrorcases.Bug (TODOs) surfaced:
package_licensesunconditionally included theoffers_dirtree artifact inpkg_filesbut, sinceship_source_offeris not declared by any dep (work in progress?),offers_diris always empty:bazel runuses symlinks, so an empty tree is useless but harmless,FileNotFoundError.The fix consists in excluding
offers_dironWindowsall platforms until the work is resumed.out_data_dirs = ["ssl", "lib/ossl-modules", "lib/engines-3"], butssl/is empty because--openssldiris set to an absolute path (C:/Program Files/…) outside the Bazel sandbox, soinstall_ssldirswrites there and leaves the sandbox copy empty =>FileNotFoundError.The fix drops
ssl/fromout_data_dirson Windows FIPS via the existingfips_windowsconfig setting.Describe how you validated your changes
Reproduced the failures locally on a Windows VM with rules_python 1.9.0, confirmed the fixes resolve them.