Skip to main content
A runner group is a set of identically configured machines: one instance type, one scaling range, one warming set. An Aspect Enterprise deployment usually has several, and your pipeline decides which one each job lands on using your CI provider’s own targeting mechanism. There is no Aspect-specific syntax.

​
The mechanism, per provider

The selector matches those values, not the group’s name, though they’re often the same. aspect-default above is an example. Your Aspect contact gives you the values for your deployment, or they’re in your Terraform if you deploy it yourself. A CircleCI job on a Workflows runner also sets working_directory: /mnt/ephemeral/workdir, the directory the runner cleans between jobs.
GitHub Actions has its own “runner groups” feature, and it’s a different thing. GitHub’s runner groups control which repositories may use an organization’s runners. Aspect Workflows runner groups define the machines. They coexist; only the names collide.
Each example includes the recommended setup step, which a job needs before it calls bazel directly. The setup step covers what it does, its inputs, and how to run it without an integration.

​
bazel and aspect both run there

Targeting is independent of what the job runs. With the setup step in place, a group takes vanilla bazel and Aspect CLI tasks equally, and you can mix them across jobs on the same group:
GitHub Actions

​
Why use more than one

Groups put different work on the hardware it needs, so the cheap common case doesn’t pay for the expensive rare one.
GitHub Actions
Common reasons to split:
  • Architecture. An Arm group for Arm targets, an x86 group for everything else.
  • Memory. One large-memory group for the link step or the test that needs 128 GiB, so the rest of the fleet doesn’t have to be that size.
  • Specialist hardware. GPUs for model training and inference tests.
  • Latency versus cost. A small group with a non-zero minimum for PR jobs; larger groups that scale from zero for scheduled work.

​
Runner groups and remote execution worker pools are different things

A runner group is where the CI job runs: the machine that checks out your repository and invokes bazel. A remote execution worker pool is where individual Bazel actions run once that invocation fans out. Without remote execution the runner group is doing all the work, and its size is the limit. With it, Bazel on the runner still schedules and dispatches every action, tracks the results and moves the outputs, so size the group to the fan-out you expect, not to the work the workers absorb.

​
Adding or changing a group

  • Self-hosted: the runner groups block in your Terraform. See the .
  • Hosted by Aspect: request it. Say what the jobs need and Aspect sizes it.
Either way, a new group needs the matching selector in your pipeline before anything lands on it.