airship.yaml, no commit to it, nothing to review — change one
line in a workflow and push.
airship.yaml, where it is
reviewed, shared and versioned with everything else.
The label format
1
airship-aws-
The prefix. Only AWS has one-line runners.
2
The instance type, with dots as dashes
t2.large becomes t2-large; m7i.metal-24xl becomes m7i-metal-24xl.
The family has to look like one of EC2’s — c7i, c7i-flex, u7i-12tb,
mac2-m2 — so a typo is simply not a one-line runner rather than a
launch that fails.3
Optionally an image
ubuntu2204 (the default) or ubuntu2404.4
Optionally spot
spot asks for spot capacity.spot tokens may come in either order, but only at the end. A
label that puts them elsewhere is not a one-line runner, and the job is
skipped with No runner serves the labels.
What you get
Everything else — disks, caching, environment variables, private networking,
idle pools, GPUs — needs a definition in
airship.yaml.
A definition always wins
If any definition’slabels include the same label, that definition is used
instead. So you can introduce airship.yaml later without changing a single
workflow file: name the definition’s label after the one-line label you were
using, and the next job picks it up.
airship.yaml
A job that also asks for
windows is never served by a one-line runner:
the Ubuntu images are Linux. Windows needs a definition naming a Windows
image.Still bounded
One-line runners obey everything else: the repository must be activated,max_runners still caps
concurrency, the machine still destroys itself after one job, and the launch
still shows up on Jobs, Runners and Events.
What they skip is the review step. On a repository where that matters — a
public one, or one where people should not be choosing 48xlarge machines
casually — keep the shapes in airship.yaml and use access
policies on the expensive ones.