Remote Execution vs Local Execution
summary
Bazel remote execution fails when builds rely on undeclared files, host-only tools, or workspace probes; expect hard errors where local runs silently succeed. Repro steps used: run a build under local Docker sandbox to surface implicit dependencies and missing platform binaries; convert ad-hoc tool invocations into explicit tool chains so tool version/location becomes part of the action key. Avoid the legacy local JDK, don’t ship host-only build binaries, and only use local fallback when the local and remote toolchains are identical.
AI-written summary · about
chapters (9)
- 0:00Remote vs local execution
- 1:58Remote execution challenges
- 5:32Implicit dependencies in builds
- 8:24Platform binaries in remote builds
- 10:30Tool invocation in rules
- 13:23Local JDK cache issues
- 15:55Workspace rules issues
- 19:47Mixing execution strategies
- 24:05Summary and next steps
related talks
50mBuilding on Key – Keeping your Actions and Remote Executions in Tune + Q&A
11mIntroducing Remote Bazel
21mDebugging and fixing build non-determinism with Bazel
06mHermetic Toolchain Creation with Local Remote Execution (LRE) & Nix
01h 31mBazel
26mBuilding Go with Bazel
11mNix and Bazel: The Odd Couple of Build Tools
33mRemote Execution with Rules_nixpkgs: Design and Deployment