Running tasks in CI - Aspect Build

What a CI step gets

When a CI step is aspect <task>, it gets these with no extra YAML or shell scripting:

Retry on transient Bazel errors. BLAZE_INTERNAL_ERROR (exit code 37) and LOCAL_ENVIRONMENTAL_ERROR (36) trigger a bounded retry, 3 attempts by default (--bazel-retry-attempts), in place of a hand-written || retry loop.
Native CI status checks. Each task posts a per-step status (named by --task:name) as a GitHub check run, a Buildkite annotation or a GitLab commit status, whichever applies, updated live while the job runs.
Lint findings on the diff. Lint findings post as PR review comments, with one-click suggested fixes when the linter offers them.
Changed-file detection. aspect format, aspect lint and aspect gazelle --scope=changed find the PR’s changed files by diffing against the merge base, and fall back to the GitHub PR Files API when git diff can’t answer (shallow clones, fetch-depth-restricted runners). They act only on what the PR touched.
Hold-the-line lint. Pre-existing violations don’t fail the build; only new ones added by the PR do, so strict lint rules don’t need a flag-day cleanup.
Artifact upload to your CI’s native storage. Test logs, the Bazel execution log, build profile (chrome trace), and the BEP upload through the CI provider’s artifact API: GitHub Actions artifacts, Buildkite artifacts, the GitLab generic package registry (enable the project’s package registry) or CircleCI store_artifacts. Each kind is opt-in.
Selective delivery. aspect delivery re-deploys only the services whose Bazel-built outputs changed since the last release, decided by output content hashes rather than git diffs or timestamps. It needs Aspect Workflows runners, which hold the delivery state.
Every task in the Build Results UI. Besides build and test, lint, format, gazelle, run, warming and delivery stream their build events, and each one’s status check links to its invocation.

On a CI runner other than Aspect Workflows, --remote defaults to auto, which configures Bazel from the default deployment. Aspect Workflows runners configure themselves; see Aspect Workflows runners.

Standard tasks

Each invoked the same way in every CI step; Aspect CLI tasks lists them all:

Command	What it does	Full reference
`aspect build --task:name build -- //...`	Build Bazel targets	aspect build / aspect test
`aspect test --task:name test -- //...`	Run Bazel tests	aspect build / aspect test
`aspect format --task:name format`	Format source files (changed files by default)	aspect format
`aspect lint --task:name lint -- //...`	Run linters with hold-the-line strategy	aspect lint
`aspect gazelle --task:name gazelle`	Generate and sync BUILD files	aspect gazelle
`aspect buildifier --task:name buildifier`	Format Starlark files (opt-in via `format.alias()`)	aspect buildifier
`aspect delivery --task:name delivery`	Deliver only targets whose outputs changed	aspect delivery

Custom tasks defined in your repo’s .aspect/*.axl files invoke the same way: aspect <name> --task:name <name>.

Task name

--task:name assigns a short name uniquely identifying the task invocation. The name appears in GitHub Status Checks, Buildkite Annotations, and similar CI-platform integrations, so pick something meaningful in a status list. Plain names matching the task kind like build or test are the right default. Suffix with a CI name (e.g. build-gha) if you run the same task on multiple CI providers simultaneously and need distinct status check names per provider. If you don’t pass --task:name, it’s auto-generated:

On CI, from the CI job name: <kind>-<job> (e.g. test-ci-linux), so status checks read meaningfully and stay stable across runs. A job whose name already is the kind, or already starts with <kind>-, keeps its own name rather than being prefixed twice — job test running aspect test gives test, and test-linux gives test-linux, not test-test-linux. A job that merely shares a leading substring, like testing, is still prefixed. If you set required status checks, check their names after upgrading to 2026.41.50 — they change for jobs in that carve-out. The job name comes from the host: GitHub Actions GITHUB_JOB, Buildkite BUILDKITE_STEP_KEY (else BUILDKITE_LABEL), CircleCI CIRCLE_JOB, GitLab CI_JOB_NAME. Steps using native parallelism append the shard index (Buildkite BUILDKITE_PARALLEL_JOB, CircleCI CIRCLE_NODE_INDEX) → <kind>-<job>-<shard>. If the same name is still generated again on the same run and machine (e.g. one job script invoking the same task kind twice), a -2, -3, … suffix is appended.
Off CI, from a random friendly suffix: <kind>-<suffix> (e.g. test-fluffy-parakeet).

Set --task:name explicitly anyway. Renaming a CI job renames every check and artifact derived from it.

GitHub Actions matrix jobs: unlike Buildkite/CircleCI parallelism, GitHub exposes no per-shard environment variable (matrix values live only in

 ${'{'}{'{'} matrix.* {'}'}{'}'}</code>, and <code>GITHUB_JOB</code> is the same for every shard), so all shards of a matrix auto-generate the same name and collapse into one PR-summary row. For per-shard status, set an explicit <code>--task:name=&lt;kind&gt;-$  matrix.os

The —task-key flag is a deprecated alias for —task:name. It still works but prints a warning and will be removed in a future release. Switch to —task:name.

Authentication

ASPECT_API_TOKEN is optional, but recommended. It enables the Aspect Cloud remote cache and the CI-platform integrations: status checks, inline PR comments, suggested fixes, and the PR Files API fallback for changed-file detection. Store the token as a CI secret on each provider you use, then pass it to aspect:

GitHub Actions: pass it via with: aspect-api-token: on the aspect-build/setup-aspect action. setup-aspect exchanges it for a short-lived JWT and persists only the JWT; the long-lived secret never lands in GITHUB_ENV and isn’t visible to other steps in the job.
Buildkite: store it as a Buildkite secret named ASPECT_API_TOKEN and expose it on each step with secrets: [ASPECT_API_TOKEN], as the examples below do.
GitLab CI, CircleCI: expose it as the ASPECT_API_TOKEN env var on the job (a masked CI/CD variable / project environment variable).

See Authenticating the Aspect CLI for the one-time account, GitHub App, and token-generation setup.

Aspect Workflows runners

On Aspect Workflows CI runners, the Workflows feature configures Bazel for the runner, with no .bazelrc changes or per-provider scripting; that page lists the flags it injects. Remote execution is opt-in through --workflows:remote-exec. aspect setup bazelrc, which the setup integrations run, writes the same flags to ~/.aspect/bazelrc, imported from ~/.bazelrc, so vanilla bazel invocations in later steps pick them up too.

Keep incompatible tasks off each other’s analysis cache

All tasks on a warm runner share one --output_base, which means one Bazel server and one analysis cache. When two tasks run with flag sets Bazel considers incompatible, such as different optimization settings (--compilation_mode), a build-affecting --config, or stamping (--stamp), the second task’s flags invalidate the first’s analysis cache, and Bazel logs Build options … have changed, discarding analysis cache. The next run pays the loading/analysis cost again even though nothing else changed. Give such a task its own Bazel server by suffixing its --output_base. Only --output_base is made unique; --output_user_root stays shared, so the install base and external-repository cache are reused rather than duplicated across servers. It’s a no-op off a Workflows runner.

Any Bazel task: the Workflows feature flag --workflows:runner-output-base-suffix=<suffix>, or in .aspect/config.axl:

.aspect/config.axl

def config(ctx: ConfigContext):
    # e.g. give a task that builds with an incompatible --config its own server
    ctx.features[Workflows].args.runner_output_base_suffix = "my-suffix"

Delivery: the delivery task has its own flag for its stamped release build. See Isolate the delivery Bazel server.

Complete pipeline examples

Pipeline examples for provider-hosted runners (GitHub Actions’ ubuntu-latest, Buildkite’s hosted agents, GitLab.com runners, CircleCI cloud runners, your own self-hosted VMs) and for Aspect Workflows CI runners, which ship with aspect pre-installed. On GitHub Actions, the same aspect-build/setup-aspect action covers both cases: it installs the launcher on provider-hosted runners, no-ops on Workflows CI runners, and exchanges ASPECT_API_TOKEN for a session JWT either way. On Buildkite, GitLab CI and CircleCI, the plugin, component and orb do the same job; see Aspect Cloud CI setup.

On provider-hosted runners

Cloud VMs and containers don’t ship with aspect or bazel, so every job starts with the setup integration, which installs the launcher and Bazelisk and logs in with ASPECT_API_TOKEN. The launcher reads .aspect/version.axl to pin the CLI version, so local and CI stay in sync. Delivery state lives on Aspect Workflows runners, so the delivery jobs here run --mode=always --track-state=false and deliver every resolved target. Every delivery job runs only on the default branch and selects its targets with --query; tag the targets you ship deliverable. See aspect delivery.

GitHub Actions
Buildkite
GitLab CI
CircleCI

.github/workflows/aspect.yaml

name: CI

on:
  push:
    branches: [main]
  pull_request:
  workflow_dispatch:

permissions:
  contents: read    # actions/checkout
  id-token: write   # artifact uploads and the PR summary comment

concurrency:
  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
  cancel-in-progress: true

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: aspect-build/setup-aspect@ebca96eb49ef58c00d4226de8bd3a0813507dd87 # v2026.38.3
        with:
          aspect-api-token: ${{ secrets.ASPECT_API_TOKEN }}
      - run: aspect build --task:name build -- //...

  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: aspect-build/setup-aspect@ebca96eb49ef58c00d4226de8bd3a0813507dd87 # v2026.38.3
        with:
          aspect-api-token: ${{ secrets.ASPECT_API_TOKEN }}
      - run: aspect test --task:name test -- //...

  format:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: aspect-build/setup-aspect@ebca96eb49ef58c00d4226de8bd3a0813507dd87 # v2026.38.3
        with:
          aspect-api-token: ${{ secrets.ASPECT_API_TOKEN }}
      - run: aspect format --task:name format

  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: aspect-build/setup-aspect@ebca96eb49ef58c00d4226de8bd3a0813507dd87 # v2026.38.3
        with:
          aspect-api-token: ${{ secrets.ASPECT_API_TOKEN }}
      - run: aspect lint --task:name lint -- //...

  delivery:
    needs: [test]
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: aspect-build/setup-aspect@ebca96eb49ef58c00d4226de8bd3a0813507dd87 # v2026.38.3
        with:
          aspect-api-token: ${{ secrets.ASPECT_API_TOKEN }}
      - run: aspect delivery --task:name delivery --ci-host=gh --mode=always --track-state=false --query='attr(tags, deliverable, //...)'

setup-aspect also installs Bazelisk and caches Bazel’s repository cache in the GitHub Actions cache. The disk cache is off by default, since the remote cache covers the same ground; disk-cache: true turns it on. Pin to a full-length SHA with the version annotated in a trailing comment per GitHub’s third-party action security guidance; find the latest SHA on the setup-aspect releases page.

.buildkite/pipeline.yaml

steps:
  - key: build
    label: ":bazel: Build"
    plugins:
      - aspect-build/setup-aspect#8de9aed254d0699baf201f66e2076fc8c09f42b9: ~ # v2026.38.2
    command: aspect build --task:name build -- //...
    secrets:
      - ASPECT_API_TOKEN

  - key: test
    label: ":bazel: Test"
    plugins:
      - aspect-build/setup-aspect#8de9aed254d0699baf201f66e2076fc8c09f42b9: ~ # v2026.38.2
    command: aspect test --task:name test -- //...
    secrets:
      - ASPECT_API_TOKEN

  - key: format
    label: ":hammer_and_wrench: Format"
    plugins:
      - aspect-build/setup-aspect#8de9aed254d0699baf201f66e2076fc8c09f42b9: ~ # v2026.38.2
    command: aspect format --task:name format
    secrets:
      - ASPECT_API_TOKEN

  - key: lint
    label: ":lint-roller: Lint"
    plugins:
      - aspect-build/setup-aspect#8de9aed254d0699baf201f66e2076fc8c09f42b9: ~ # v2026.38.2
    command: aspect lint --task:name lint -- //...
    secrets:
      - ASPECT_API_TOKEN

  - key: delivery
    label: ":package: Delivery"
    depends_on: [test]
    if: build.branch == pipeline.default_branch
    plugins:
      - aspect-build/setup-aspect#8de9aed254d0699baf201f66e2076fc8c09f42b9: ~ # v2026.38.2
    command: aspect delivery --task:name delivery --mode=always --track-state=false --query='attr(tags, deliverable, //...)'
    secrets:
      - ASPECT_API_TOKEN

secrets: needs Buildkite agent v3.106.0 or later.

.gitlab-ci.yml

# ASPECT_API_TOKEN: a masked CI/CD variable in Settings → CI/CD → Variables.
include:
  - component: $CI_SERVER_FQDN/aspect-build/setup-aspect-gitlab-component/setup@2026.38.3

workflow:
  rules:
    - if: '$CI_PIPELINE_SOURCE != "schedule"'

stages:
  - CI

build:
  extends: .setup-aspect
  stage: CI
  script:
    - aspect build --task:name build -- //...

test:
  extends: .setup-aspect
  stage: CI
  script:
    - aspect test --task:name test -- //...

format:
  extends: .setup-aspect
  stage: CI
  script:
    - aspect format --task:name format

lint:
  extends: .setup-aspect
  stage: CI
  script:
    - aspect lint --task:name lint -- //...

delivery:
  extends: .setup-aspect
  stage: CI
  needs: [test]
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  script:
    - aspect delivery --task:name delivery --ci-host=gl --mode=always --track-state=false --query='attr(tags, deliverable, //...)'

.circleci/config.yml

# ASPECT_API_TOKEN: a project environment variable or context secret.
version: 2.1

orbs:
  setup-aspect: aspect-build/setup-aspect@2026.38.2

parameters:
  force_targets:
    type: string
    default: ""

workflows:
  ci:
    jobs:
      - build
      - test
      - format
      - lint
      - delivery:
          requires: [test]
          filters:
            branches:
              only: main
    when:
      not:
        equal:
          - scheduled_pipeline
          - << pipeline.trigger_source >>

jobs:
  build:
    docker:
      - image: cimg/base:current
    steps:
      - checkout
      - setup-aspect/setup
      - run: aspect build --task:name build -- //...

  test:
    docker:
      - image: cimg/base:current
    steps:
      - checkout
      - setup-aspect/setup
      - run: aspect test --task:name test -- //...

  format:
    docker:
      - image: cimg/base:current
    steps:
      - checkout
      - setup-aspect/setup
      - run: aspect format --task:name format

  lint:
    docker:
      - image: cimg/base:current
    steps:
      - checkout
      - setup-aspect/setup
      - run: aspect lint --task:name lint -- //...

  delivery:
    docker:
      - image: cimg/base:current
    environment:
      ASPECT_WORKFLOWS_DELIVERY_FORCE_TARGETS: << pipeline.parameters.force_targets >>
    steps:
      - checkout
      - setup-aspect/setup
      - run: aspect delivery --task:name delivery --ci-host=circle --mode=always --track-state=false --query='attr(tags, deliverable, //...)'

On Aspect Workflows CI runners

Aspect Workflows CI runners ship with aspect and bazel pre-installed and warm. The delivery jobs run only on the default branch, as above. The runs-on: / agents: / tags: / resource_class: value targets your Workflows CI runner queue (aspect-default here is an example; use the queue of one of your ).

GitHub Actions
Buildkite
GitLab CI
CircleCI

.github/workflows/aspect-workflows.yaml

name: Aspect Workflows

on:
  push:
    branches: [main]
  pull_request:
  workflow_dispatch:

permissions:
  contents: read    # actions/checkout
  id-token: write   # artifact uploads and the PR summary comment

concurrency:
  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
  cancel-in-progress: true

jobs:
  build:
    runs-on: [self-hosted, aspect-workflows, aspect-default]
    steps:
      - uses: actions/checkout@v6
      - uses: aspect-build/setup-aspect@ebca96eb49ef58c00d4226de8bd3a0813507dd87 # v2026.38.3
        with:
          aspect-api-token: ${{ secrets.ASPECT_API_TOKEN }}
      - run: aspect build --task:name build -- //...

  test:
    runs-on: [self-hosted, aspect-workflows, aspect-default]
    steps:
      - uses: actions/checkout@v6
      - uses: aspect-build/setup-aspect@ebca96eb49ef58c00d4226de8bd3a0813507dd87 # v2026.38.3
        with:
          aspect-api-token: ${{ secrets.ASPECT_API_TOKEN }}
      - run: aspect test --task:name test -- //...

  format:
    runs-on: [self-hosted, aspect-workflows, aspect-default]
    steps:
      - uses: actions/checkout@v6
      - uses: aspect-build/setup-aspect@ebca96eb49ef58c00d4226de8bd3a0813507dd87 # v2026.38.3
        with:
          aspect-api-token: ${{ secrets.ASPECT_API_TOKEN }}
      - run: aspect format --task:name format

  lint:
    runs-on: [self-hosted, aspect-workflows, aspect-default]
    steps:
      - uses: actions/checkout@v6
      - uses: aspect-build/setup-aspect@ebca96eb49ef58c00d4226de8bd3a0813507dd87 # v2026.38.3
        with:
          aspect-api-token: ${{ secrets.ASPECT_API_TOKEN }}
      - run: aspect lint --task:name lint -- //...

  delivery:
    needs: [test]
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    runs-on: [self-hosted, aspect-workflows, aspect-default]
    steps:
      - uses: actions/checkout@v6
      - uses: aspect-build/setup-aspect@ebca96eb49ef58c00d4226de8bd3a0813507dd87 # v2026.38.3
        with:
          aspect-api-token: ${{ secrets.ASPECT_API_TOKEN }}
      - run: aspect delivery --task:name delivery --ci-host=gh --query='attr(tags, deliverable, //...)'

setup-aspect skips the launcher install on Workflows CI runners (the runner image already ships aspect) and runs aspect setup bazelrc to write ~/.aspect/bazelrc, imported from ~/.bazelrc, so vanilla bazel calls in later steps pick up the same runner configuration.

.buildkite/pipeline.yaml

steps:
  - key: build
    label: ":bazel: Build"
    plugins:
      - aspect-build/setup-aspect#8de9aed254d0699baf201f66e2076fc8c09f42b9: ~ # v2026.38.2
    command: aspect build --task:name build -- //...
    secrets:
      - ASPECT_API_TOKEN
    agents:
      queue: aspect-default

  - key: test
    label: ":bazel: Test"
    plugins:
      - aspect-build/setup-aspect#8de9aed254d0699baf201f66e2076fc8c09f42b9: ~ # v2026.38.2
    command: aspect test --task:name test -- //...
    secrets:
      - ASPECT_API_TOKEN
    agents:
      queue: aspect-default

  - key: format
    label: ":hammer_and_wrench: Format"
    plugins:
      - aspect-build/setup-aspect#8de9aed254d0699baf201f66e2076fc8c09f42b9: ~ # v2026.38.2
    command: aspect format --task:name format
    secrets:
      - ASPECT_API_TOKEN
    agents:
      queue: aspect-default

  - key: lint
    label: ":lint-roller: Lint"
    plugins:
      - aspect-build/setup-aspect#8de9aed254d0699baf201f66e2076fc8c09f42b9: ~ # v2026.38.2
    command: aspect lint --task:name lint -- //...
    secrets:
      - ASPECT_API_TOKEN
    agents:
      queue: aspect-default

  - key: delivery
    label: ":package: Delivery"
    depends_on: [test]
    if: build.branch == pipeline.default_branch
    plugins:
      - aspect-build/setup-aspect#8de9aed254d0699baf201f66e2076fc8c09f42b9: ~ # v2026.38.2
    command: aspect delivery --task:name delivery --query='attr(tags, deliverable, //...)'
    secrets:
      - ASPECT_API_TOKEN
    agents:
      queue: aspect-default

The queue: aspect-default value must match the queue of one of your .

.gitlab-ci.yml

# ASPECT_API_TOKEN: a masked CI/CD variable in Settings → CI/CD → Variables.
include:
  - component: $CI_SERVER_FQDN/aspect-build/setup-aspect-gitlab-component/setup@2026.38.3

workflow:
  rules:
    - if: '$CI_PIPELINE_SOURCE != "schedule"'

stages:
  - CI

build:
  extends: .setup-aspect
  stage: CI
  tags: [aspect-workflows, aspect-default]
  script:
    - aspect build --task:name build -- //...

test:
  extends: .setup-aspect
  stage: CI
  tags: [aspect-workflows, aspect-default]
  script:
    - aspect test --task:name test -- //...

format:
  extends: .setup-aspect
  stage: CI
  tags: [aspect-workflows, aspect-default]
  script:
    - aspect format --task:name format

lint:
  extends: .setup-aspect
  stage: CI
  tags: [aspect-workflows, aspect-default]
  script:
    - aspect lint --task:name lint -- //...

delivery:
  extends: .setup-aspect
  stage: CI
  needs: [test]
  tags: [aspect-workflows, aspect-default]
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  script:
    - aspect delivery --task:name delivery --ci-host=gl --query='attr(tags, deliverable, //...)'

The aspect-default tag must match the queue of one of your .

.circleci/config.yml

# ASPECT_API_TOKEN: a project environment variable or context secret.
version: 2.1

orbs:
  setup-aspect: aspect-build/setup-aspect@2026.38.2

parameters:
  force_targets:
    type: string
    default: ""

workflows:
  aspect-workflows:
    jobs:
      - build
      - test
      - format
      - lint
      - delivery:
          requires: [test]
          filters:
            branches:
              only: main
    when:
      not:
        equal:
          - scheduled_pipeline
          - << pipeline.trigger_source >>

jobs:
  build:
    machine: true
    resource_class: YOUR-ORG/aspect-default
    working_directory: /mnt/ephemeral/workdir
    steps:
      - checkout
      - setup-aspect/setup
      - run:
          name: Build
          command: aspect build --task:name build -- //...

  test:
    machine: true
    resource_class: YOUR-ORG/aspect-default
    working_directory: /mnt/ephemeral/workdir
    steps:
      - checkout
      - setup-aspect/setup
      - run:
          name: Test
          command: aspect test --task:name test -- //...

  format:
    machine: true
    resource_class: YOUR-ORG/aspect-default
    working_directory: /mnt/ephemeral/workdir
    steps:
      - checkout
      - setup-aspect/setup
      - run:
          name: Format
          command: aspect format --task:name format

  lint:
    machine: true
    resource_class: YOUR-ORG/aspect-default
    working_directory: /mnt/ephemeral/workdir
    steps:
      - checkout
      - setup-aspect/setup
      - run:
          name: Lint
          command: aspect lint --task:name lint -- //...

  delivery:
    machine: true
    resource_class: YOUR-ORG/aspect-default
    working_directory: /mnt/ephemeral/workdir
    environment:
      ASPECT_WORKFLOWS_DELIVERY_FORCE_TARGETS: << pipeline.parameters.force_targets >>
    steps:
      - checkout
      - setup-aspect/setup
      - run:
          name: Delivery
          command: aspect delivery --task:name delivery --ci-host=circle --query='attr(tags, deliverable, //...)'

Replace YOUR-ORG/aspect-default with the resource class you created in CircleCI.

Live examples

The aspect-build/bazel-examples repo runs these pipelines on GitHub Actions, Buildkite, GitLab CI and CircleCI. On GitHub Actions it runs both the provider-hosted-runner and Workflows-CI-runner versions side by side; Buildkite, GitLab CI, and CircleCI each run the Workflows-CI-runner version. Source lives in two places: GitHub (used by the GitHub Actions, Buildkite, and CircleCI pipelines) and GitLab (used by the GitLab CI pipeline).

CI provider	Live pipeline
GitHub Actions	Actions tab
Buildkite	Recent builds
GitLab CI/CD	Pipelines
CircleCI	Pipeline runs

What `aspect <task>` reports back

aspect <task> posts task results to these surfaces. The examples below are from real runs of aspect-build/aspect-cli’s own CI:

PR task summary comment: a single comment the Aspect Workflows GitHub App posts to the PR thread summarizing every task in the pipeline. See example →
GitHub status checks: one check per aspect <task> invocation, named by --task:name, surfaced on the PR’s Checks tab and on the commit itself.
Buildkite annotations (when running on Buildkite): one annotation per aspect <task> invocation, rendered at the top of the build page.

Per-task links from a recent run. The task name links to its GitHub status check; the Buildkite column links to the matching annotation.

Task (GitHub Status Check)	Buildkite annotation
`aspect build`	build #3019 →
`aspect test`	build #3019 →
`aspect format`	build #3019 →
`aspect buildifier`	build #3019 →
`aspect lint`	build #3019 →
`aspect gazelle`	build #3019 →
`aspect delivery`	build #3019 →

​What a CI step gets

​Standard tasks

​Task name

​Authentication

​Aspect Workflows runners

​Keep incompatible tasks off each other’s analysis cache

​Complete pipeline examples

​On provider-hosted runners

​On Aspect Workflows CI runners

​Live examples

​What aspect <task> reports back

What a CI step gets

Standard tasks

Task name

Authentication

Aspect Workflows runners

Keep incompatible tasks off each other’s analysis cache

Complete pipeline examples

On provider-hosted runners

On Aspect Workflows CI runners

Live examples

What `aspect <task>` reports back