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.
Workflows has the following components:
- A terraform module called
workflowsthat can be used from your existing infrastructure-as-code setup.
- A Node.js application called
rosettawhich abstracts the details of spawning the
You can see Workflows in action on our open-source repositories.
Here is the configuration file in aspect-build/bazel-lib:
This configuration is shockingly short, because Workflows has all the right defaults to run Bazel.
We use a few CI systems, but prefer Buildkite. Here are the builds for the bazel-lib project:
We use the CI system's dynamic pipelines feature, so the actual configuration for CI is generated when a request arrives.
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:
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.
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:
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.