> ## Documentation Index
> Fetch the complete documentation index at: https://site.aspect.build/llms.txt
> Use this file to discover all available pages before exploring further.

# aspect ci warming

> Migrate the legacy rosetta run warming + warming_archive two-step to a single aspect ci warming task on Aspect Workflows runners.

The legacy Rosetta warming job ran two commands — `rosetta run warming` to populate the caches, then `/etc/aspect/workflows/bin/warming_archive` to upload them to the warming bucket. `aspect ci warming` replaces both with a single task: it cleans the runner's prior Bazel state, runs `bazel build --nobuild` against the given targets to populate the repository, output, and Bazel caches, and — on an Aspect Workflows runner — uploads the populated caches to the warming bucket itself.

Warming runs on a schedule (typically daily) to pre-populate an Aspect Workflows runner group's shared caches, so the first real CI job of the day starts warm instead of building everything from cold.

<Info>
  `aspect ci warming` requires Aspect CLI `v2026.26.44` or newer.
</Info>

## What changed

| Area                   | Rosetta                                                                    | `aspect ci warming`                                                               |
| ---------------------- | -------------------------------------------------------------------------- | --------------------------------------------------------------------------------- |
| Invocation             | `rosetta run warming` **then** `/etc/aspect/workflows/bin/warming_archive` | `aspect ci warming -- //...` (one step; runs the archiver itself on a runner)     |
| Targets                | Whole repo (from the `.aspect/workflows/config.yaml` warming task)         | Positional patterns, default `//...` (e.g. `aspect ci warming -- //services/...`) |
| Cache populate         | `rosetta run warming`                                                      | `bazel build --nobuild` against the targets                                       |
| Archive upload         | Separate `warming_archive` invocation                                      | Built in — invoked automatically on a Workflows runner                            |
| Off a Workflows runner | n/a                                                                        | The cache-populate step still runs; the archive step is skipped with a warning    |
| Workflows config       | Needs `.aspect/workflows/config.yaml` with a `warming` task                | None                                                                              |

## Configuration

`aspect ci warming` takes positional target patterns plus a few flags:

* **Targets** (positional, default `//...`) — the Bazel target patterns to warm.
* **`--bazel-flag=<flag>`** (repeatable) — extra flags forwarded to the underlying `bazel build` (e.g. `--bazel-flag=--config=ci`).
* **`--bazel-startup-flag=<flag>`** (repeatable) — extra Bazel startup flags.

```shell theme={null}
aspect ci warming -- //...                       # warm everything (default)
aspect ci warming -- //services/... //libs/...    # warm a subset
aspect ci warming --bazel-flag=--config=ci -- //...
```

## Examples

Run warming on a schedule against your main branch. The job replaces the old two-command warming step with a single `aspect ci warming`.

**Before** — `.aspect/workflows/config.yaml` plus a warming job running `rosetta run warming` + `warming_archive`.

**After** — a scheduled CI job:

<Info>
  The warming task itself doesn't need the `setup-aspect` plugin: it always runs on an Aspect Workflows CI runner where `aspect` is already on the `PATH`, and it makes no vanilla `bazel` calls. The GitHub Actions example still uses the action because it provides the auth `aspect` needs to post its status check; on other providers, supply `ASPECT_API_TOKEN` instead (see the comments in the examples).
</Info>

<CodeGroup>
  ```yaml GitHub Actions theme={null}
  name: Aspect Workflows Warming

  on:
    schedule:
      - cron: '0 12 * * *'  # 7 AM ET (UTC-5)
    workflow_dispatch:

  permissions:
    id-token: write

  jobs:
    warming:
      runs-on: [self-hosted, aspect-workflows, aspect-default]
      steps:
        - uses: actions/checkout@v4
        - uses: aspect-build/setup-aspect@2306377a61c45954ab2df7c7311698b109364352 # v2026.26.9
          with:
            aspect-api-token: ${{ secrets.ASPECT_API_TOKEN }}
        - name: Warming
          run: aspect ci warming --task:name warming -- //...
  ```

  ```yaml Buildkite theme={null}
  steps:
    - label: ":fire: Warming"
      agents:
        queue: aspect-default
      command: aspect ci warming --task:name warming -- //...
  ```

  Create a scheduled pipeline in Buildkite (**Settings > Schedules > New Schedule**) targeting this pipeline, e.g. `0 12 * * *` (7 AM ET, UTC).

  ```yaml GitLab theme={null}
  warming:
    tags: [aspect-workflows, aspect-default]
    stage: CI
    rules:
      - if: '$CI_PIPELINE_SOURCE == "schedule"'
    script:
      - aspect ci warming --task:name warming -- //...
  # Set ASPECT_API_TOKEN as a masked CI/CD variable in Settings → CI/CD → Variables.
  ```

  Create a pipeline schedule in GitLab (**Build > Pipeline schedules > New schedule**), e.g. `0 12 * * *` (7 AM ET).

  ```yaml CircleCI theme={null}
  workflows:
    aspect-workflows-warming:
      jobs:
        - warming
      when:
        and:
          - equal:
            - scheduled_pipeline
            - << pipeline.trigger_source >>
          - equal:
            - aspect-workflows-warming
            - << pipeline.schedule.name >>

  jobs:
    warming:
      machine: true
      resource_class: YOUR-ORG/aspect-default
      working_directory: /mnt/ephemeral/workdir
      steps:
        - checkout
        - run:
            name: Warming
            command: aspect ci warming --task:name warming -- //...
  # Set ASPECT_API_TOKEN as a project environment variable or context secret.
  ```
</CodeGroup>

Each provider triggers the job on its own schedule: a GitHub Actions `schedule:` cron, a Buildkite scheduled pipeline, a GitLab pipeline schedule, or a CircleCI scheduled pipeline — as shown in the examples above. Point it at your main branch and run it as often as your cache churn warrants (daily is typical).