Work around intermittent Windows build failure (missing pyconfig.h. etc.) (#48188)

rdesgroppes · web-flow · commit f9026689bca5 · 2026-03-23T11:27:02.000Z
### 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>
diff --git a/.bazelrc b/.bazelrc
@@ -41,6 +41,12 @@ common:macos --remote_local_fallback_strategy=sandboxed
 
 # Windows config -------------------------------------------------------------------------------------------------------
 common:windows --strategy=standalone # Valid values are: [dynamic_worker, standalone, dynamic, remote, worker, local]
+# TODO(agent-build): rules_python 1.9.0 transitions py_binary to enable_runfiles=true on Windows, creating a second
+# Bazel configuration. build_python.bat writes PCbuild/ intermediate files into the shared execroot source tree, so two
+# concurrent builds of python_win (one per configuration) race on those files. Setting enable_runfiles globally makes
+# the transition a no-op (same flag value => same config hash => one build). The proper fix is to make build_python.bat
+# hermetic by redirecting MSBuild's OutDir and intermediate paths to $(@D) instead of the source tree.
+common:windows --enable_runfiles
 # Neither repo_env nor shell_executable affect action keys. It can be both an advantage and a disadvantage.
 # For instance, if we need to have some special behavior in bash we can add it, however, in some cases
 # it may lead to cache poisoning.
