Keith Smiley
Keith Smiley
That would make sense with our solution to this which was to launch bazel with `env -i` and only pass very limited variables (and a static PATH variable)
2 practical workarounds for this today: 1. use `tools/bazel` and re-exec `$BAZEL_REAL` with `env PATH=whatever` 2. `--repo_env=PATH=... --action_env=PATH=... --test_env=PATH=...`
this will be required for bazel 9.x https://github.com/bazelbuild/bazel/commit/0522f8e58bf864005207eb8f09162d35ddd1f678, so probably want to merge this soon since that's ~2 months away
nice investigation! seems like we should add it there
@buildbreaker2021 can you review this? this is the same as https://github.com/bazelbuild/rules_cc/pull/196 but for the workspace to fix https://github.com/bazelbuild/bazel/issues/20513
@buildbreaker2021 can you check on this one
this version landed in https://github.com/bazelbuild/bazel-central-registry/pull/4199, sorry i missed this
no strong pref on adding this or not but note that `swift:swift.bzl` is the equivalent today
you can probably use this workaround https://github.com/bazelbuild/bazel-central-registry/blob/b09573344e6fa0c1dc7c706c6dfa5ef7f56f4eee/modules/swift-syntax/600.0.0-prerelease-2024-07-24/presubmit.yml#L10 if apple_support already is in the dep tree
cc @AttilaTheFun who might be able to help here too I think we need to keep our universal_protoc rule to support shared caches across x86_64 and arm64, so I guess...