Skip to main content
Version: 5.1.x

Aspect Workflows

Aspect Workflows is a convenient drop-in Bazel CI/CD pipeline that works with your existing CI or Remote Execution providers.

Workflows is available with an Aspect Pro subscription. For a free three-month trial, visit https://aspect.build/workflows.

High-level design

Workflows has the following components:

  • A terraform module called workflows that can be used from your existing infrastructure-as-code setup.
  • A Node.js application called rosetta which abstracts the details of spawning the bazel CLI.
info

Rather than vanilla Bazel, Workflows always runs the Aspect CLI since it has some additional commands that we rely on, such as aspect outputs.

Demo

You can see Workflows in action on our open-source repositories.

Here is the configuration file in aspect-build/bazel-lib:

.aspect/workflows/config.yaml
---
env:
CC: /bin/false
workspaces:
- .
- e2e/bzlmod
- e2e/copy_to_directory
tasks:
test:

This configuration is shockingly short, because Workflows has all the right defaults to run Bazel.

Build generation

We use a few CI systems, but prefer Buildkite. Here are the builds for the bazel-lib project:

https://buildkite.com/aspect/bazel-lib/builds?branch=main

We use the CI system's dynamic pipelines feature, so the actual configuration for CI is generated when a request arrives.

note

You can check in the generated CI configuration in your repo if you want to edit it by hand.

Buildkite allows you to inspect the generated config in the User Interface by expanding the "Setup Aspect CI" step and looking in the Timeline tab. The "Uploaded Pipeline Steps" shows ~100 lines of YAML configuration was produced for our build:

Buildkite generated pipeline

Behind the scenes, Workflows has deployed an elastic pool of build agents using an EC2 Auto-Scaling Group. When a new machine boots, it is "warmed up" so that even the first build it performs is incremental. As a result, you can see that our builds are under two minutes, even though this repository has low traffic and so build agents generally expire and builds launch on fresh instances.

Annotations

Developers can crawl through the whole Bazel log, but it may be hundreds of lines of spam. Or, they could click away from the CI results page to some dedicated "Bazel results UI" which shows much more information than they wanted, and requires yet another interface.

Our approach leverages the Aspect CLI, which has a Buildkite plugin. This lets us show build failures in an intuitive way on the page a developer is already looking at.

For example, here's a recent failure from a PR to that bazel-lib project:

Buildkite failure annotation

We see that the test failures are reported, with their JUnit XML files parsed. We link to the log file for each test failure, and provide a "how to reproduce" code snippet.