The Aspect CLI (Documentation Index
Fetch the complete documentation index at: https://docs.aspect.build/llms.txt
Use this file to discover all available pages before exploring further.
aspect) is a free, open-source task runner built on top of Bazel. It absorbs the pile of shell scripts and CI YAML that every Bazel monorepo eventually grows — format pre-submits, lint enforcement, BUILD-file generation, release-tag delivery — and replaces it with a single command-line tool that behaves identically on a developer laptop and in CI. Built-in tasks like aspect build and aspect test work out of the box; custom tasks are Starlark functions you drop into your repo and invoke as aspect <name>.
This page walks you from a fresh install to a custom task in about ten minutes. Apache-licensed, no Aspect account required — everything below works locally and your existing bazel workflow keeps working alongside it.
1. Install the CLI
aspect-launcher binary as aspect on your PATH. The launcher is a thin shim that downloads and runs the actual CLI — like bazelisk for Bazel, or nvm for Node.
See How to install the Aspect CLI for other installation methods (Homebrew, GitHub Actions, bazel_env, manual download).
Verify the install:
2. Build and test a Bazel repo
aspect build, aspect test, and aspect run work in any Bazel workspace. If you have an existing repo, jump there. Otherwise, create a tiny one to play with:
bazel command under the hood — same Bazel flags pass through, same exit code — with these additions on top:
- A status line summarising the task and its phases (
🔨 Build,🧪 Test,🚀 Run) - Automatic retry on transient Bazel errors (
BLAZE_INTERNAL_ERROR,LOCAL_ENVIRONMENTAL_ERROR) - A consistent task lifecycle that CI integrations can hook into (status checks, annotations, artifact upload)
3. Discover what’s available
| Command | What it does |
|---|---|
aspect build | Build Bazel targets |
aspect test | Run Bazel tests with optional LCOV coverage |
aspect run | Build and run a binary target |
aspect format | Format only the files changed in the PR |
aspect lint | Run linters with hold-the-line strategy |
aspect gazelle | Generate and sync BUILD files |
aspect delivery | Deliver only targets whose outputs actually changed |
aspect <task> --help shows every flag for a specific task with its current default.
4. Pin the CLI version
For reproducible builds across developers and CI, pin the CLI version in your repo:.aspect/version.axl
aspect-cli binary the first time it’s needed, then caches it. Every developer and every CI runner ends up on the same version regardless of when they installed the launcher.
See How to pin the Aspect CLI version for custom sources (local builds, internal mirrors, alternate registries).
5. Customize tasks in config.axl
Built-in tasks accept configuration via .aspect/config.axl at the repo root. The file is evaluated once per invocation — locally and in CI — so a single edit changes behaviour everywhere.
This config activates a --config=ci group from your .bazelrc when the CI env var is set, and turns on test-log artifact upload for failures:
.aspect/config.axl
BazelTrait.extra_flags are forwarded to every bazel invocation the CLI makes. ArtifactUpload uploads test logs, BEP, Bazel profiles, and execution logs to your CI platform’s native artifact storage. Both are documented in aspect build & aspect test.
6. Write your first custom task
When the built-ins don’t cover what you need, write your own. Custom tasks are Starlark functions you register with thetask() built-in. Drop them in any .axl file inside .aspect/ and they’re auto-discovered as CLI commands (see How tasks are registered for the other registration paths):
.aspect/build-and-list.axl
aspect help — your new build-and-list task appears alongside the built-ins (the variable name’s underscores become dashes in the command):
7. Run the same tasks in CI
The version of the CLI pinned in.aspect/version.axl is used by the launcher to fetch the matching CLI on first invocation, so local and CI stay in sync as long as the launcher is on PATH.
On GitHub Actions, use the aspect-build/setup-aspect action — it installs the launcher (a no-op on Aspect Workflows CI runners, where aspect is pre-installed), installs Bazelisk, and wires up GHA caching.
On Buildkite, GitLab, and CircleCI you install the launcher inline with the curl one-liner. (On Aspect Workflows runners the launcher is pre-installed regardless of provider — skip the install step.)
Set up ASPECT_API_TOKEN (recommended)
ASPECT_API_TOKEN is optional, but setting it up unlocks the CI features that make aspect worth running in CI in the first place: GitHub Status Checks on every PR, inline lint findings as PR review comments, one-click suggested fixes, and more accurate changed-file detection for aspect format and aspect lint. Without it the tasks still build and test normally — the platform integrations just silently skip.
One-time setup, all of which is walked through in detail in Authenticating the Aspect CLI:
- Sign up for a free Aspect account at signup.aspect.build (no credit card required).
- Install the Aspect Workflows GitHub App on your GitHub org and link it to your Aspect account from the authentication page. The App is what lets the CLI post status checks, PR comments, and suggested fixes back to GitHub.
- Generate an
ASPECT_API_TOKENin the API Tokens portal. The token is a<CLIENT_ID>:<SECRET>string — copy it as soon as it’s displayed (the secret half is shown only once). - Store the token as a CI secret on each provider you use:
- GitHub Actions — Settings → Secrets and variables → Actions → New repository secret, named
ASPECT_API_TOKEN. - Buildkite — store it in your secret manager and reference it from
env:(your-buildkite-secret-refin the example below). - GitLab CI — Settings → CI/CD → Variables → Add variable, masked, named
ASPECT_API_TOKEN. - CircleCI — Project Settings → Environment Variables → Add Environment Variable (or a Context if you want to share across projects).
- GitHub Actions — Settings → Secrets and variables → Actions → New repository secret, named
with: aspect-api-token: — this keeps the long-lived secret out of GITHUB_ENV so other steps in the job can’t see it.
Where to next
- Tasks overview — full reference for every built-in task with config options and CI examples.
- How to run and define tasks — deep dive on writing custom tasks: arguments, processes, filesystem, build queries, phases, cleanup.
- How to use external AXL modules — pull in extension libraries like
rules_lintviaMODULE.aspect. - AXL reference — every type, function, and module that AXL exposes.
- Aspect Workflows — purpose-built Bazel CI runners that detect
aspecttasks automatically and apply remote cache, RBE, and pre-warmed output bases.

