Building on Key – Keeping your Actions and Remote Executions in Tune + Q&A
summary
A remote execution client (Bazel + BuildFarm) can take minutes or hours not because remote CPUs are slow but because of serial costs: Merkle tree composition, huge find_missing_blobs requests, parallel uploads/downloads, and Java heap GC. A Docker image build at UberATG spends ~750s remotely versus 0.03s locally because uploads/downloads and the default 60s client timeout (RBE guidance: 3600s) dominate. Practical fixes: use no_remote/local tags, enable progressive uploads and downloads, add interceptors to blacklist or throttle large actions and fail fast.
AI-written summary · about
chapters (11)
- 0:00Remote execution challenges
- 3:51Slow remote builds frustrate
- 10:21Remote execution workflows
- 16:21Bazel’s concurrent execution
- 21:01Resource costs in execution
- 27:48Upload/download bottlenecks
- 31:39Client-side info during execution
- 35:10Good vs bad remote actions
- 40:47Fixing slow actions
- 44:59Future improvements
- 47:03Q&A
related talks
24mFaster Builds With Remote Execution and Caching
11mIntroducing Remote Bazel
26mRemote Execution vs Local Execution
28mBazel Remote Execution and Remote Caching
29mPost Mortems for 4 Years of Remote Execution
23mWalk, Run, Fly - Take your build pipeline to the next level!
27mImproving the Usability of Remote Caching
11mAction Deduplication: Faster and Cheaper Remote Builds Without Lifting a Finger