At BuildBuddy, our core mission is to make builds faster. We use Firecracker snapshots to keep warmed-up workers available on demand.

With as little as a curl request, you can run any bash command in a warm worker.

We're excited to announce that BuildBuddy's remote execution platform now supports the ARM64 (AArch64) architecture. This means you can run your builds and tests natively on ARM64 executors, unlocking faster builds for ARM64 targets and enabling teams to test on the same architecture they deploy to.

Autoscaled Cloud ARM Support​

For several years now, we’ve supported native ARM64 builds using Bring Your Own Runners (BYOR) or using our cloud mac build machines. As more customers transition to the ARM architecture for cost or performance reasons, we want to make it even easier for your builds to run natively on Linux + ARM64 as well. So we’re closing the loop and adding support for autoscaled cloud Linux ARM64 runners. This means that no matter how big your build, we’re able to handle it, and you’ll only pay for the resources you actually use.

We’ve made it easy to get started with ARM builds by adding support to the buildbuddy-toolchain to automatically detect your architecture and set the platform appropriately. This makes maintaining a project that builds on both ARM64 and x86-64 ergonomic and easy, and removes the need for slow cross-compilation.

Getting Started​

Configuring your Bazel build to use BuildBuddy's arm64 executors is straightforward. Add the BuildBuddy toolchain to your MODULE.bazel file:

bazel_dep(name = "toolchains_buildbuddy", version = "0.0.4")

# Use the extension to create toolchain and platform targets
buildbuddy = use_extension("@toolchains_buildbuddy//:extensions.bzl", "buildbuddy")

Then build your project with remote execution enabled, and your build will run on the new ARM64 executors.

Example ARM build of Abseil

As always, please report any problems you find to us either on our GitHub repo or come chat with us on Slack!

BuildBuddy's remote execution engine merges in-flight executions of identical actions to save our users time and resources. In this blog post, we'll explain why action merging is important, how it works, and some fun stuff we've learned over the years running our implementation in production.

At BuildBuddy, our mission is to bring the world's best developer tools to every company. In order to achieve this mission, we need to build a team that has experience using Bazel at scale. That's why we're so excited to share that Tyler French is joining BuildBuddy's engineering team.

Tyler joins us from Uber. He's a maintainer of Bazel's rules_go and gazelle repos and has given Bazelcon talks on Optimizing Gazelle Performance in Uber's Monorepo and How Uber Manages Go Dependencies with Bzlmod.

We look forward to working alongside Tyler to build the future of developer tools.

Welcome to BuildBuddy, Tyler!

At BuildBuddy, our mission is to bring the world's best developer tools to every company. In order to achieve this mission, we need to build a team that has experience leading and scaling the fastest growing developer tools companies in the world. That's why we're so excited to share that Dan Stowell is joining BuildBuddy's engineering team.

Dan joins us from Vercel, where he was a Director of Engineering. Prior to Vercel, Dan was the Head of Engineering at Replit and a Principal Engineer at Spotify.

We look forward to working alongside Dan to build the future of developer tools.

Welcome to BuildBuddy, Dan!

We discovered a bug in Bazel that was causing builds with --remote_download_minimal to download all output artifacts.

A fix has been submitted upstream to the Bazel repository and will be included in the Bazel 9.x release. It will also be cherry-picked back to versions 8.2.0 and 7.6.0.

Users on older versions of Bazel can work around this issue by setting --experimental_remote_cache_ttl to a large value, such as 10000d, with some caveats.

Upgrading Bazel and the related dependencies can sometimes lead to unexpected issues. These issues can range from build failures to runtime errors, and generally, they can be hard to troubleshoot.

So today, we will discuss how to narrow down the root cause of build failures after a dependency upgrade using git bisect.

At BuildBuddy, our mission is to bring the world's best developer tools to every company. A core part of that mission involves building systems and infrastructure that can handle the scale of the world's largest enterprises. That's why we're so excited to share that Vanja Pejovic is joining BuildBuddy's engineering team.

Vanja joins us from Google, where he spent over 12 years as a Software Engineer. He brings with him his experience working on Google's internal RBE (remote build execution) system, Forge.

We look forward to working alongside Vanja to build the future of developer tools.

Welcome to BuildBuddy, Vanja!

At BuildBuddy, our mission is to bring the world's best developer tools to every company. A core part of that mission involves building around the open source Bazel ecosystem to give every engineer fast, reproducible, and correct builds.

That's why we're so excited to share that Fabian Meumertzheim has joined BuildBuddy as a Staff Software Engineer. His contributions to Bazel have already greatly benefited BuildBuddy users, and Fabian will continue to focus on open source Bazel contributions in his role with us.

Fabian is a maintainer of Bazel's rules_go, gazelle, rules_jni, and with_cfg. He's also a regular contributor to the Bazel Slack, and has been the most prolific Bazel contributor over the past couple of years that's not currently employed by Google.

Fabian joins us from Code Intelligence, where he worked on building tools for fuzz testing.

We look forward to working alongside Fabian to build the future of developer tools.

Welcome to BuildBuddy, Fabian!

The promise of Bazel is the promise of fast builds. So what do you do if your build was slow? Curse out the developer that convinced your company to migrate to Bazel? Of course not! You’d never do that, right? 🙂

BuildBuddy is here to help. Bazel provides a lot of helpful information to debug slow builds, but it can be overwhelming to know where to look.

Do you have an iOS app, or really any Apple-based project, that you want to migrate to Bazel? With this guide I'll show you how to migrate your project, using the Mastodon iOS project as an example.

We will use iOS based rules in the example migration, but similar rules exist in rules_apple for the other Apple platforms, including macOS, watchOS, tvOS, and visionOS.

The completed migration is available in my fork of mastodon-ios. You can follow along with the changes made in the following sections by checking out this commit first. At the end of some sections there will be a link to a new commit that includes the changes mentioned up to that point.

In our last post, we summarized the changes that were in the Bazel 7.0 release. There were a lot of changes though, so it can be hard to determine which ones are impactful to you and why.

Don't worry, we've got your back. In this post we highlight the changes that help BuildBuddy users build even faster!