Google had a company-wide FuzzIt hackathon recently, so I went digging
in gRPC and found this, which means I probably don't know what I'm doing :)
The initial corpus files I'm checking in were generated via local runs
and appear to consistently cause leaks. Please let me know if these are
actual bugs, or if they're a false positive.
Turns out that putting this in the main build definition starklark file
means that our users will also incur a dependency on the repo rule.
That's no bueno.
This reverts commit 78e443b4f6.
* Remove the toolchains //third_party/toolchains:local and //third_party/toolchains:local_large.
* Remove the platforms :rbe_ubuntu1604, :rbe_ubuntu1604_large, :local and :local_large.
* No longer inherit from @rbe_default//config:platform but instead use it directly. It is now the only non-windows platform.
* When creating @rbe_default//config:platform directly with rbe_autoconfig, set dockerAddCapabilities and dockerPrivileged directly in the exec_properties field. No need to set dockerNetwork to "off" and dockerSiblingContainers to false since these are the defaults.
* Also set gceMachineType = "n1-highmem-2" on the default platform. This value can be overridden by specific targets that want to use LARGE_MACHINE.
* Use create_exec_properties_dict where appropriate.
* Use custom_exec_properties to define LARGE_MACHINE.
I wasn't able to test thoroughly that this PR does not break any existing targets. I was not able to run anything on windows/mac and I also don't have access to gRPC's RBE setup.