You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm playing with an old toy project of mine, and I've locked it down to Bazel 3.3.1.
Unfortunately, unlike running Bazelisk locally, the environment set up without buildbuddy.yaml sets up some config files that seem to make Bazelisk pass on --heap_dump_on_oom to Bazel, which is unsupported in 3.3.1 and a bunch of versions after that.
Luckily, it looks like none of my custom Starlark rules are broken up to 6.5.0, but still, --heap_dump_on_oom being passed without an easy opt-out made moving to something newer mandatory, even though RBE itself with local Bazelisk seems to otherwise work perfectly fine.
The text was updated successfully, but these errors were encountered:
Looks like the flag was added in Bazel 5.0 which was released back in January of 2022. Agreed we should probably add a config option to buildbuddy.yaml to disable this or not apply it if we detect an old Bazel version. (cc @bduffany)
Hi,
I'm playing with an old toy project of mine, and I've locked it down to Bazel 3.3.1.
Unfortunately, unlike running Bazelisk locally, the environment set up without
buildbuddy.yaml
sets up some config files that seem to make Bazelisk pass on--heap_dump_on_oom
to Bazel, which is unsupported in 3.3.1 and a bunch of versions after that.Luckily, it looks like none of my custom Starlark rules are broken up to 6.5.0, but still,
--heap_dump_on_oom
being passed without an easy opt-out made moving to something newer mandatory, even though RBE itself with local Bazelisk seems to otherwise work perfectly fine.The text was updated successfully, but these errors were encountered: