Skip to main content

BuildBuddy v2.5.0 Release Notes

We're excited to share that v2.5.0 of BuildBuddy is live on both Cloud Hosted BuildBuddy and open-source via Github, Docker, and our Helm Charts!

Thanks to everyone using open source, cloud-hosted, and enterprise BuildBuddy. We've made lots of improvements in this release based on your feedback.

New in v2.5.0#

  • The new global filter - BuildBuddy collects lots of build information across CI and local builds. In order to make navigating these builds easier, we've introduced a new global filter. The global filter allows you to filter by status and role on any page - with more options including user, repo, and branch coming soon.

  • Date picker - To complement the new global filter, we've also added a date picker. The date picker allows you to select a time range and see builds, trends, etc. for exactly the time period you're interested in.

  • Clickable trends - Now that you can filter any view by date, we've added a feature to the Trends page that allows you to click on a data point and be taken to a filtered view of builds from just that time period. As part of this change, the trends page now also respects your local time zone.

  • Branch information - BuildBuddy now collects information about a build's git branch in addition to the repo and commit info already collected. This makes it even easier to navigate your builds.

  • Light terminal theme - For those of you who suffer from eye strain when reading light text on dark backgrounds: we've heard your feedback. We've added a new light terminal theme that can be enabled in your personal settings.

  • Improved flaky test support - Flaky tests can destroy developer productivity. To make them easier to deal with, we've added a new feature that calls out flaky tests & timeouts more explicitly. We've also improved the behavior of our RBE to reduce flakes due to timeouts when caused by external factors like Docker image pulls.

  • Remote executions tab - We've had a hidden feature for a while that allowed you to click on the Remote execution on label to see an overview of remotely executed actions for RBE builds. We've now promoted this feature to its own Executions tab. With this change come new features like search and filtering.

  • Action input & output files - When clicking on an individual remotely executed actions, we now have a new file viewer that allows you to navigate the input files of the action. You can click on any of these files (as well as any output files the action has) to download them from the remote cache.

  • Action timing - The timing tab gives you a breakdown of execution timing from Bazel's point of view, but there's another story to tell from the remote executor's point of view. Action pages now show a visual breakdown of time spent in queue, downloading inputs, executing, and uploading outputs for each remotely executed action.

  • Revamped settings page - We've revamped the settings page to make it easier to manage your BuildBuddy account.

  • And much much more - Every release comes packed with so many new features, performance improvements and bug fixes that we can't get to them all. Here are some more highlights:
    • Support for serving static files from a CDN
    • Support for MinIO as a storage backend
    • Buildkite links now link to the specific Buildkite job that spawned the invocation
    • Support for distributed tracing backends like Jaeger, Google Cloud Trace, and others

That's it for this release. Stay tuned for more updates coming soon!

As always, we love your feedback - join our Slack channel or email us at hello@buildbuddy.io with any questions, comments, or thoughts.

Author:

Siggi Simonarson

Siggi Simonarson

Co-founder @ BuildBuddy

Meet BuildBuddy Workflows

Traditional CI systems, like Jenkins, Travis, CircleCI, and BuildKite, are built around the concept of a pipeline. Pipelines allow you to specify a list of build/test steps to run for each commit or pull request to your repo. Pipelines are great because you can run many in parallel across multiple machines. Unfortunately, there are often dependencies between these pipelines, for example a build step that must be completed before a test step can begin.

Some tools, like GitLab Pipelines, attempt to solve this problem by allowing you to specify dependencies between pipelines. This approach is better, but forces you to manually maintain the relationships between pipelines in a pile of YAML configuration files. As the number of dependencies grow, any sufficiently complex CI system starts to resemble a build system.

None of these pipeline-based approaches are well suited for Bazel's approach to dependency management and remote build execution, which involves generating a Directed Acyclic Graph of all build and test actions. Bazel's approach allows for optimal parallelization and caching of these actions. It also enables rebuilding and retesting only affected targets, saving both engineering time and compute resources.

Introducing a Bazel-focused CI Solution#

In today's BuildBuddy v2.3 release, which is now live on BuildBuddy Cloud, we're launching BuildBuddy Workflows. BuildBuddy Workflows is a Continuous Integration (CI) solution for Bazel repositories hosted on GitHub (with support for other providers coming soon).

Like other CI solutions, Workflows give you the confidence that your code builds successfully and passes all tests before you merge pull requests or deploy a new release.

But because BuildBuddy Workflows were built for Bazel repos and tightly integrated with BuildBuddy RBE and Remote Caching, they are really fast.

How fast are BuildBuddy Workflows?#

We've used BuildBuddy Workflows on our own repos for the past few months, comparing them side-by-side with our existing CI solution built on GitHub Actions with BuildBuddy RBE and Remote Caching enabled.

By leveraging warm, hosted, Bazel processes, as well as BuildBuddy's remote caching and execution, Workflows dramatically sped up our CI runs. Compared to our previous solution (which used BuildBuddy RBE and Remote Caching on GitHub Runners), we reduced the median duration by nearly 8X — with most CI runs completing in just a few seconds.

This overlapping histogram chart shows the complete picture. Note that the majority of BuildBuddy workflow runs took 30 seconds or less, while nearly all runs on GitHub Actions took at least 2 minutes and 15 seconds:

overlapping histogram comparing BuildBuddy and GitHub actions

How did we make BuildBuddy Workflows so fast?#

In addition to convenience and security, one of our main goals for Workflows was to maximize performance, even for very large source repositories.

We did this in two main ways:

  1. Ensuring a fast network connection between Bazel and BuildBuddy's RBE & caching servers.
  2. Running workflows against hosted, warm, Bazel instances.

Fast connection to BuildBuddy RBE#

In our experience, network latency is often the biggest bottleneck in many Bazel Remote Build Execution and Remote Caching setups.

The solution here was simple: run Workflows on executors in the same datacenters where BuildBuddy RBE and Cache nodes are deployed.

With GitHub actions or other CI solutions, the network connection might be fast (particularly after the recent network optimizations we made in BuildBuddy v2) — but not nearly as fast as having workflow runners on the same local network as BuildBuddy itself.

Hosted, Warm, Bazel instances#

Once you have a sufficiently fast RBE and Remote Caching setup, and have removed network bottlenecks — the CI bottleneck often becomes Bazel's analysis phase.

By re-using warm Bazel processes when possible, we're able to re-use Bazel's analysis cache across CI runs of the same repo. This can save several minutes per build, depending on the size of your repository and the number of external dependencies being pulled in.

This is similar to how Google's Build Dequeuing Service performs workspace selection:

A well-chosen workspace can increase the build speed by an order of magnitude by reusing the various cached results from the previous execution. [...] We have observed that builds that execute the same targets as a previous build are effectively no-ops using this technique

How do I use BuildBuddy Workflows?#

BuildBuddy Workflows are launching today, in Beta, for all GitHub users. You can get started with BuildBuddy Workflows by checking out our setup guide. If you've already linked your GitHub account to BuildBuddy, it'll only take about 30 seconds to enable Workflows for your repo — just select a repo to link, and we'll take care of the rest!

Other changes in BuildBuddy v2.3#

While the main focus of BuildBuddy v2.3 has been on launching BuildBuddy Workflows, the release also contains several other features, in addition to lots of bug fixes and performance improvements.

Dependency graph visualization#

We added dependency graph visualizations for bazel query commands that use the --output graph parameter. This visualization is zoom-able and pan-able, and can render graphs with thousands of edges.

Here's an example of a command you can run to generate a graph:

bazel query '//...' --output graph --bes_backend=cloud.buildbuddy.io --bes_results_url=https://app.buildbuddy.io/invocation/

And the resulting output:

Bazel query dependency graph visualization

Clickable RBE Actions#

For actions executed with BuildBuddy Remote Build Execution, you can now click on individual actions to get the full set of command arguments, environment variables, execution metadata, output files, and more:

RBE actions view

That's it for this release! As always, message us on Slack or file an issue if you need help, run into any issues, or have feature requests!

Author:

Brandon Duffany

Brandon Duffany

Engineer @ BuildBuddy

Introducing BuildBuddy v2

Our mission at BuildBuddy is to make developers more productive. When we released the first version of BuildBuddy a little over a year ago, we were blown away by the demand for tools and techniques for speeding up common developer workflows like building, testing, and debugging code. We've been working hard ever since - using our own tools to build the next generation of developer tooling for all.

Today we're excited to announce v2 of BuildBuddy! We've completely revamped our caching and remote build execution infrastructure to give our users and customers the one thing they care about above all else: speed.

When optimizing the performance of a remote build execution system, there are 3 critical bottlenecks: Caching, Sandboxing, and Execution. We've made order of magnitude improvements in each of these areas, bringing clean, uncached build times for TensorFlow (7,000+ actions) on BuildBuddy RBE down from 28 minutes last August to just 3.47 minutes with BuildBuddy v2. This build takes over 4 hours (250 min) on a 3.3GHz i7 Macbook Pro.

Caching#

The biggest remote build execution bottleneck is right in the name: remote. This means we have to ship source files, tools, and other inputs needed to execute the build from the host machine to a remote cluster of build servers over the network.

In BuildBuddy v2, some of the many improvements in this area include:

  • Completely revamped caching infrastructure for microsecond read/write latencies
  • Improved batch performance for quickly moving 100k+ small files
  • Load balancer optimizations to improve large file throughput

For a more in-depth look at optimizing for high throughput and low latency, we highly recommend this great article from the Dropbox Engineering team which was incredibly helpful in identifying and fixing bottlenecks.

All of these improvements, when taken together, have driven a colossal improvement in both upload and download throughput across file sizes. We have more work to do in this area, but we're really pleased with the results in this release.

Sandboxing#

Once we've got all of the inputs we need to execute an action on a remote executor, the next step is to set up the execution root. One of Bazel's core features is the ability to perform hermetic builds. In order to achieve this, we spin up a clean Docker container for each action to execute in. This is similar to Bazel's docker spawn strategy.

While this helps ensure that remotely executed actions are hermetic, there is often a trade-off between hermeticity and performance. You can make this trade-off locally using Bazel's different spawn strategies: sandboxed, local, and worker.

When using remote build execution, you typically don't have the ability to make these trade-offs. That's why we've introduced 3 new features that give users back some of that control. By default, actions will still be executed in clean Docker images - but if you specify one of the following execution properties, you can alter that behavior:

  • recycle-runner: actions will still be executed in a clean execution root - but the executor will re-use an existing docker image from a pool of re-usable containers. This is similar in behavior to Bazel's sandboxed execution strategy.
  • preserve-workspace: actions will re-use an execution root from a pool of re-usable workspaces and only download inputs that have been added or changed since the previously executed action, while cleaning up any outputs. This is similar in behavior to Bazel's local execution strategy.
  • persistent-workers: the executor will use the persistent-worker protocol to communicate with actions that support them. This can help speed up certain build actions that support persist workers (like Java, Scala, Typescript, and others) by 2-4x. This execution property can be applied at the target level for actions that support them. We've also added support for the proposed persistentWorkerKey execution property which removes the need for target-level specification. This is similar in behavior to Bazel's worker execution strategy.

Execution#

Now that we've got our inputs on the executor, and our execution root set up, our final step is the actual execution.

We've made significant improvements here as well:

  • We've upgraded our default executor cluster to run on compute-optimized Intel Cascade Lake machines with up to 3.8 GHz sustained all-core turbo.
  • Our Mac executors now run on bare-metal Mac minis, which show huge improvements over the previous Orka machines we used for I/O intensive workloads.
  • Our new caching and auto-scaling infrastructure supports scaling up and down from just a few executors to hundreds of machines depending on load while still supporting the --remote_download_minimal flag.
  • The groundwork has been laid for what we call Bring Your Own Executors. This will allow users to take advantage of BuildBuddy's UI and global caching infrastructure while running their own executor pools.

Other improvements#

While our focus for v2 has been on RBE performance, we've made plenty of other improvements in this release:

  • Improved query performance for large customers with 1 million+ invocations
  • Added hinted handoff for write failures
  • Fetches are now displayed in the results UI
  • Timing tab improvements
  • Right click to copy downloadable artifact URLs
  • Lots and lots of reliability improvements
  • Default Xcode version configuration options

We have several big announcements coming in the next few weeks, so stay tuned for more!

As always, we love your feedback - join our Slack channel or email us at hello@buildbuddy.io with any questions, comments, or thoughts.

Happy Building!

Author:

Siggi Simonarson

Siggi Simonarson

Co-founder @ BuildBuddy

BuildBuddy Achieves SOC 2 Certification

Our mission at BuildBuddy is to help developers be more productive. It's our highest priority to make sure that your data is safe so that you can focus on what matters: building your product.

Today, we’re excited to share that BuildBuddy has achieved SOC 2 certification.

The audit was conducted by The Cadence Group, compliance specialists who have performed SOC reporting examinations for some of the largest software companies in the world. Our certification means that we adhere to the highest standards of security, processing integrity, and risk management.

Our SOC 2 Report outlines how we encrypt our customer’s data, control access to our systems, scan for vulnerabilities, respond to incidents, and more.

In addition to completing our SOC 2 audit, we've partnered with Vanta to continuously monitor our SOC 2 compliance and ensure that the security practices we've put in place are being followed.

We’re happy to discuss our security policies in more detail or send over a copy of our SOC 2 report. Please feel free to reach out to us at security@buildbuddy.io for more information!

Author:

George Li

George Li

Head of Sales @ BuildBuddy

BuildBuddy v1.8.0 Release Notes

We're excited to share that v1.8.0 of BuildBuddy is live on Cloud Hosted BuildBuddy, Enterprise, and Open Source via GitHub, Docker, and our Helm Charts!

Thanks to everyone using open source, cloud-hosted, and enterprise BuildBuddy. We've made lots of improvements in this release based on your feedback.

A special thank you to our new open-source contributor:

  • Ashley Davies who contributed several pull requests to our Helm charts in order to make them easier to use in clusters that already have an Nginx controller deployed.

And a warm welcome to our three new team members! 

  • Pari Parajuli who joins our engineering team as an intern who's currently studying at University of California, Berkeley.
  • Vadim Berezniker who joins our engineering team after 7 years at Google on the Google Cloud team.
  • Zoey Greer who joins us as a software engineer from the Google Search team.

We're excited to continue growing BuildBuddy and fulfill our mission of making developers more productive!

Our focus for this release was on reliability, performance, improved documentation, and making BuildBuddy easier to release and monitor.

New in v1.8.0#

  • Read-only API keys - when using Bazel remote caching, teams often need to configure which machines have write access to the cache. While Bazel has some flags to control cache writes, using these can be error prone and insecure. BuildBuddy now makes this easy by introducing the ability to create both read-only and read+write api keys on your organization settings page. You can create as many API keys (and certificates) as you'd like and distribute them to your CI machines, workstations, and other endpoints.

  • Improved docs - we've completely revamped our documentation and added support for tables of contents, syntax highlighting, better navigation, dark mode (!!), interactive widgets, and an "Edit this page" button that links directly to the correct file in our GitHub docs directory for submitting pull requests. With these great new features, we'll be ramping up documentation on both new and existing BuildBuddy features to make the lives of BuildBuddy users easier.

  • Testing improvements - we've invested heavily in our testing infrastructure, adding new integration tests and test fixtures that make testing BuildBuddy's interactions with Bazel easier. This will lead to more stable releases and faster iteration cycles going forward.

  • Remote execution improvements - we've made more speed and reliability improvements to our remote build execution platform, including faster cache hit checking, faster auth checks, and better support for iOS builds.

  • Buildkite integration - invocations that are kicked off from Buildkite now link back to the Buildkite job that triggered them.

  • Grafana - our Helm charts make deploying BuildBuddy to Kubernetess cluster a breeze. One thing that's been tricky for many users has been accessing the Prometheus data that BuildBuddy exports in an easily digestible format. To fix this, we made it easy to deploy Grafana and Prometheus via our Helm charts with just a couple lines of configuration. It comes out of the box with a default dashboard that shows popular BuildBuddy metrics and can be easily extended to add more graphs.

  • More to come - we've been laying the groundwork for two major projects that will go live in the coming weeks to make building and testing your Bazel projects even faster.

That's it for this release. Stay tuned for more updates coming soon!

As always, we love your feedback - join our Slack channel or email us at hello@buildbuddy.io with any questions, comments, or thoughts.

Author:

Siggi Simonarson

Siggi Simonarson

Co-founder @ BuildBuddy

BuildBuddy v1.5.0 Release Notes

We're excited to share that v1.5.0 of BuildBuddy is live on both Cloud Hosted BuildBuddy and open-source via Github, Docker, and our Helm Charts!

Thanks to everyone using open source, cloud-hosted, and enterprise BuildBuddy. We've made lots of improvements in this release based on your feedback.

A special thank you to our new open-source contributor:

  • Corbin McNeely-Smith who contributed to making our auth flow more resilient to error cases, and made our health-check handlers more flexible to support different load-balancers.

Our focus for this release was on giving users more visibility into test flakiness, monitoring & scaling improvements, and security hardening.

New in v1.5.0#

  • Test flakiness dashboard - one of the feature requests we get most frequently from BuildBuddy users is the ability to collect target-level data and analyze it across invocations. Today we're taking the first step in the direction with our new test dashboard. The test dashboard allows you to monitor per-target test statuses by commit - so you can quickly identify and fix flaky test targets that slow down developer velocity. It also has a timing view that gives you a heat-map to quickly identify slow targets. This is just the first step we're taking in exposing more target-level data and are excited to build additional features based on your feedback!

  • Prometheus metrics - we've added a ton of new Prometheus metrics to BuildBuddy that allow open-source and Enterprise users to monitor not only BuildBuddy's performance, but the overall health of their developer productivity efforts. This allows you to hook into existing monitoring and alerting tools like Grafana to analyze and get notified when your developers are experiencing issues. Metrics include build duration, cache hit & miss rates, remote execution queue length, and more. For a full list of the new metrics we now expose, see our Prometheus metric documentation. Interested in some metrics that aren't on this list? Let us know!

  • Auto-scaling - with the addition of our new Prometheus metrics, we've also made improvements to the autoscaling capabilities of BuildBuddy executors. Now in addition to scaling off of raw compute metrics like CPU and RAM, BuildBuddy executors can also be configured to scale based on executor queue length and other custom metrics. This allows you to achieve better performance under heavy load while also managing your compute resources more efficiently and cost-effectively.

  • Security hardening - as part of our SOC 2 compliance controls, BuildBuddy undergoes regularly scheduled penetration tests by paid security professionals. This release contains fixes for all three non-critical findings from our January 2021 pen-test.

  • Memory leak fixes - we found and fixed 2 memory leaks in our BuildBuddy app (using our new Prometheus metrics!) that would occasionally cause BuildBuddy app servers to restart due to memory pressure.

  • Mac executor bug fix - we fixed a tricky bug caused by quirks in the way OS X handles hard-linking that significantly improves the reliability of our Mac RBE executors.

  • More bug fixes - there are lots of other bug fixes in this release including improved deadline and timeout handling, executor task scheduling improvements, and more!

That's it for this release. Stay tuned for more updates coming soon!

As always, we love your feedback - join our Slack channel or email us at hello@buildbuddy.io with any questions, comments, or thoughts.

Author:

Siggi Simonarson

Siggi Simonarson

Co-founder @ BuildBuddy

BuildBuddy v1.4.0 Release Notes

We're excited to share that v1.4.0 of BuildBuddy is live on both Cloud Hosted BuildBuddy and open-source via Github and Docker!

Thanks to everyone using open source, cloud-hosted, and enterprise BuildBuddy. We've made lots of improvements in this release based on your feedback.

A special thank you to our new contributors who we'll soon be sending BuildBuddy t-shirts and holographic BuildBuddy stickers:

  • Daniel Purkhús who enabled environment variable expansion in BuildBuddy config files & more

  • Joshua Katz who added support for auto-populating build metadata from GitLab CI invocations

Our focus for this release was on giving users new tools to share, compare, analyze, and manage BuildBuddy invocations - as well as major performance and reliability improvements to our remote build execution service.

We're also excited to share that over the coming weeks and months, we'll be open sourcing much more of BuildBuddy - including our remote build execution platform. At BuildBuddy we're firmly committed to open source and believe that a transparent and open model is the only way to build truly great developer infrastructure for all.

New to Open Source BuildBuddy#

  • Invocation sharing & visibility controls - while you've always been able to share BuildBuddy links with members of your organization, it's been difficult to share invocations more broadly (in GitHub issues or on StackOverflow). Now that working from home is the new norm, sharing links to your build logs or invocations details and artifacts has become more important than ever. To support this, we've added a Share button on the invocation page that allows you to control visibility of your invocations (this can be disabled at the organization level). We've also disabled the expiration of invocations and build logs for everyone on BuildBuddy Cloud - so you can share BuildBuddy links with confidence.

  • Invocation diffing - we've all run into the problem where a build works on your machine, but not on your coworker's machine. To support debugging these kinds of issues, we've added the ability to diff builds straight from the invocations page. This allows you to quickly find any flags or invocation details that may have changed between builds. Stay tuned for more diffing features here, including cache hit debugging and more.

  • Suggested fixes - as software engineers, we often find ourselves bumping into errors and issues that many others have bumped into before. A tool like BuildBuddy provides the perfect way to quickly surface these suggested fixes to developers quickly, without even so much as a Google search. We've started by adding suggestions for common issues that BuildBuddy users run into, but stay tuned for the ability to add your own custom fix suggestions and share them with your organization and beyond!

  • Easy invocation deletion - you can now delete your BuildBuddy invocations directly from the invocation page "three dot" menu in case you want to share an invocation and delete it when you're done.

New to Cloud & Enterprise BuildBuddy#

  • Cache stats & filters - our trends page now allows you to see trends in caching performance broken down by the Action Cache (AC) and the Content Addressable Store (CAS). The trends page is now also filterable by CI vs non-CI builds, and by user, repo, commit, or host.

  • Simplified API key header auth - previously if you wanted to authenticate your BuildBuddy invocations using an API key (instead of using certificated based mTLS), you had to place your API key in each BuildBuddy flag that connected to BuildBuddy with YOUR_API_KEY@cloud.buildbuddy.io. This has been greatly simplified in this release with the support for the --remote_header flag, which allows you to more easily separate auth credentials into a separate .bazelrc file.

  • Organization creation and invitations - you can now create organizations and send invitation links to others.

  • Remote build execution performance and reliability improvements - we've made a whole host of changes to our remote build execution executors and schedulers to make them more fault tolerant, easier to scale, and faster. We've also exposed support for executor pools on BuildBuddy Enterprise which allow you to route remote execution traffic based on OS, CPU architecture, GPU requirements, CPU/memory requirements, and more. Routing can be configured at both the platform and individual target level. Finally, we've added improved documentation to help get up and running with RBE more quickly.

That's it for this release. Stay tuned for more updates coming soon!

As always, we love your feedback - join our Slack channel or email us at hello@buildbuddy.io with any questions, comments, or thoughts.

Author:

Siggi Simonarson

Siggi Simonarson

Co-founder @ BuildBuddy

Welcoming George Li, Head of Sales

To fulfill our mission of bringing the world's best developer tools to every company, we're building a team that's ready to work with the world's best enterprises. That's why we're excited to share today that George Li is joining BuildBuddy to lead our enterprise sales efforts as our Head of Sales.

George joins us from Looker where he served as Head of APAC Sales Engineering. He joined Google Cloud through their acquisition of Looker in February, having helped the company grow to a $2.6B valuation.

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

Welcome to BuildBuddy, George!

Author:

Siggi Simonarson

Siggi Simonarson

Co-founder @ BuildBuddy

BuildBuddy v1.3.0 Release Notes

Excited to share that v1.1.0 of BuildBuddy is live on both Cloud Hosted BuildBuddy and open source via Github and Docker!

Thanks to everyone that has tested open source and cloud-hosted BuildBuddy. We've made lots of improvements in this release based on your feedback.

A special thank you to our new contributors:

Our focus for this release was on our new Remote Build Execution platform. This release marks a huge step in fulfilling our mission of making developers more productive by supporting the Bazel ecosystem.

BuildBuddy's Remote Build Execution platform supports executing your Bazel build and tests in parallel across thousands of machines with automatic scaling, support for custom Docker images, and more. We've been iterating on and testing BuildBuddy RBE for months with companies of different sizes, and are excited to now make it available to everyone.

While BuildBuddy RBE is not yet fully open source, we're offering Cloud RBE for free to individuals and open source projects to show our appreciation to the open source community.

We'll be adding more documentation on getting started with BuildBuddy RBE in the coming weeks, but in the meantime feel free to email us at rbe@buildbuddy.io or ping us in the BuildBuddy Slack and we'll be happy to help you get started.

New to Open Source BuildBuddy#

  • Cache & remote execution badges - BuildBuddy invocations pages now show badges that indicate whether or not caching and remote execution are enabled. Clicking on these badges takes you to instructions on how to configure these if they're enabled for your BuildBuddy instance.

  • Remote build execution configuration options - the BuildBuddy configuration widget has now been updated to enable configuring of remote build execution if it's enabled for your BuildBuddy instance.

  • Better build status support - BuildBuddy now better distinguishes between in-progress, failed, passed, and cancelled builds with new colorful status indicators, favicons, and more.

  • Improved documentation and new website - we've completely revamped the BuildBuddy documentation, and it's now sync'd between GitHub and buildbuddy.io/docs/, so your docs will be fresh regardless of where you're reading them. We'll be adding new sections on configuring RBE in the coming weeks. We've also completely revamped the BuildBuddy website to make it easier to navigate and perform actions like requesting a quote, or subscribing to our newsletter.

  • Test run grid - BuildBuddy will now automatically display test runs as a grid when a single test target is run more than 10 times. This supports the use case of finding and fixing flaky tests by running them with --runs_per_test=100.

  • Performance and reliability improvements - we put a lot of work into improving performance and reliability in this release. This includes changes like better event flushing (no more getting stuck on 15 build events), better shutdown behavior, speed improvements and optimizations in build artifact uploading and downloading, and more.

New to Cloud & Enterprise BuildBuddy#

  • Remote Build Execution - BuildBuddy Cloud and enterprise on-prem now support Remote Build Execution. Features include custom Docker image support, automatic scaling, multiple caching layers, and more. Additional features like Mac support, viewing of remote build actions in BuildBuddy, and more are coming soon.

  • Invocation grouping - BuildBuddy invocations can now be grouped by commit and by repo. These can be populated in one of three ways:
  1. automatically by common CI environments like CircleCI and GitHub actions
  2. manually by using build flags --build_metadata=REPO_URL= and --build_metadata=COMMIT_SHA=
  3. by using a --workspace_status_command script like this one

  • New cloud endpoint - BuildBuddy now exposes a L7 load balanced gRPCS cloud endpoint at cloud.buildbuddy.io which can be used for BES, cache, and remote execution (see our .bazelrc for an example). We'll gradually be migrating users to this from the old events.buildbuddy.io, and cache.buildbuddy.io endpoints with port numbers.

  • Easier enterprise deployment - deploying enterprise BuildBuddy is now just as easy as deploying open source BuildBuddy, with a one line install script that deploys to your Kubernetes cluster. It takes your BuildBuddy configuration file as a parameter so you can easily configure things to your needs.

That's it for this release. Stay tuned for more updates coming soon!

As always, we love your feedback - email us at hello@buildbuddy.io with any questions, comments, or thoughts.

Author:

Siggi Simonarson

Siggi Simonarson

Co-founder @ BuildBuddy

BuildBuddy v1.1.0 Release Notes

Excited to share that v1.1.0 of BuildBuddy is live on both Cloud Hosted BuildBuddy and open source via Github and Docker!

Thanks to everyone that has tested open source and cloud-hosted BuildBuddy. We've made lots of improvements in this release based on your feedback.

A special thank you to our new contributors:

Our focus for this release was on our new Remote Build Execution platform. This release marks a huge step in fulfilling our mission of making developers more productive by supporting the Bazel ecosystem.

BuildBuddy's Remote Build Execution platform supports executing your Bazel build and tests in parallel across thousands of machines with automatic scaling, support for custom Docker images, and more. We've been iterating on and testing BuildBuddy RBE for months with companies of different sizes, and are excited to now make it available to everyone.

While BuildBuddy RBE is not yet fully open source, we're offering Cloud RBE for free to individuals and open source projects to show our appreciation to the open source community.

We'll be adding more documentation on getting started with BuildBuddy RBE in the coming weeks, but in the meantime feel free to email us at rbe@buildbuddy.io or ping us in the BuildBuddy Slack and we'll be happy to help you get started.

New to Open Source BuildBuddy#

  • Cache & remote execution badges - BuildBuddy invocations pages now show badges that indicate whether or not caching and remote execution are enabled. Clicking on these badges takes you to instructions on how to configure these if they're enabled for your BuildBuddy instance.

  • Remote build execution configuration options - the BuildBuddy configuration widget has now been updated to enable configuring of remote build execution if it's enabled for your BuildBuddy instance.

  • Better build status support - BuildBuddy now better distinguishes between in-progress, failed, passed, and cancelled builds with new colorful status indicators, favicons, and more.

  • Improved documentation and new website - we've completely revamped the BuildBuddy documentation, and it's now sync'd between GitHub and buildbuddy.io/docs/, so your docs will be fresh regardless of where you're reading them. We'll be adding new sections on configuring RBE in the coming weeks. We've also completely revamped the BuildBuddy website to make it easier to navigate and perform actions like requesting a quote, or subscribing to our newsletter.

  • Test run grid - BuildBuddy will now automatically display test runs as a grid when a single test target is run more than 10 times. This supports the use case of finding and fixing flaky tests by running them with --runs_per_test=100.

  • Performance and reliability improvements - we put a lot of work into improving performance and reliability in this release. This includes changes like better event flushing (no more getting stuck on 15 build events), better shutdown behavior, speed improvements and optimizations in build artifact uploading and downloading, and more.

New to Cloud & Enterprise BuildBuddy#

  • Remote Build Execution - BuildBuddy Cloud and enterprise on-prem now support Remote Build Execution. Features include custom Docker image support, automatic scaling, multiple caching layers, and more. Additional features like Mac support, viewing of remote build actions in BuildBuddy, and more are coming soon.

  • Invocation grouping - BuildBuddy invocations can now be grouped by commit and by repo. These can be populated in one of three ways:
  1. automatically by common CI environments like CircleCI and GitHub actions
  2. manually by using build flags --build_metadata=REPO_URL= and --build_metadata=COMMIT_SHA=
  3. by using a --workspace_status_command script like this one

  • New cloud endpoint - BuildBuddy now exposes a L7 load balanced gRPCS cloud endpoint at cloud.buildbuddy.io which can be used for BES, cache, and remote execution (see our .bazelrc for an example). We'll gradually be migrating users to this from the old events.buildbuddy.io, and cache.buildbuddy.io endpoints with port numbers.

  • Easier enterprise deployment - deploying enterprise BuildBuddy is now just as easy as deploying open source BuildBuddy, with a one line install script that deploys to your Kubernetes cluster. It takes your BuildBuddy configuration file as a parameter so you can easily configure things to your needs.

That's it for this release. Stay tuned for more updates coming soon!

As always, we love your feedback - email us at hello@buildbuddy.io with any questions, comments, or thoughts.

Author:

Siggi Simonarson

Siggi Simonarson

Co-founder @ BuildBuddy