airship.yaml lives at the root of each activated repository and describes
the machines that repository can ask for. Anything Airship does not recognise
is an error naming the field, so a typo fails the check rather than quietly
doing nothing.
airship.yaml
Fields
string
required
Unique within the file. Letters, digits,
., _ and -.string
required
aws, gcp or azure. The named cloud must be connected, or jobs for this
definition are skipped with No cloud.string | string[]
required
An EC2 instance type (
c7i.xlarge), a Compute Engine machine type
(n2-standard-4), or an Azure VM size as the API spells it
(Standard_D4s_v5). See Machine types.string | mapping | list
default:"ubuntu2204"
What to boot. Each cloud accepts its own forms, plus the
ubuntu2204 and
ubuntu2404 aliases for Canonical’s newest image for the architecture. See
Machine images.string | string[]
An AWS region; a Google Cloud zone or region; an Azure region as the API
spells it. Defaults to the connected cloud’s default region.
boolean | boolean[]
default:"false"
Spot capacity. Cheaper, and reclaimable — pair it with an on-demand
fallback. See Fallbacks.
string[]
required
The
runs-on labels this runner serves. Every one must start with
airship-. See Labels and runs-on.string | false
A GPU name. Installs the NVIDIA driver on Ubuntu images that lack one and
adds the
gpu label. false, no or null turns it off. See
GPUs.mapping
Everything cloud-specific: disks, networking, environment, caching. Keys
belonging to another cloud are refused by name, so a definition copied
between clouds fails on the first wrong key rather than silently ignoring
it.
mapping
Keep runners booted and registered in advance. Exactly one of
replicas,
schedule or usage_based. See Idle
runners.extra_config
Each key below is documented on the page that covers the thing it changes.Which file a job reads
A job readsairship.yaml at its own commit, so a branch or a pull
request can try a new machine type before it is merged.
Idle runners are the exception: they are read
from the default branch only, since they exist before any job does. A push to
the default branch updates them within a reconcile pass.
A job is planned once, when GitHub first reports it queued. Editing the file
afterwards does not change how a waiting job is served.
Checking a file before you commit it
The Repositories page has a checker that parses a file and shows the machines it would plan — cheaper than a push. The developer API exposes the same check, so you can wire it into a workflow of its own.A fuller example
airship.yaml