Skip to main content
Three places hold the answer, in this order:

Jobs

Why a job is not being served, in plain words.

Events

Why a launch failed, with your cloud’s own message.

Runners

What state a machine reached, and its instance ID.

Why a job was not run

The Jobs page shows one of these reasons.

”No runner matching labels” from GitHub

This is GitHub’s message, not Airship’s, and it is the most common first-run surprise:
No runner matching the specified labels was found: self-hosted
GitHub only queues a job for a self-hosted label once a runner carrying that label has existed at least once. On the very first push in a new repository, none has. Push again. Airship registered the labels on the first attempt, so the second one queues properly. If it keeps happening:
Compare the labels on the Runners page with the job’s runs-on. Everything from -- onwards is ignored when matching, so airship-build--123 matches a definition with airship-build, but airship-buildd--123 matches nothing.
A job on [self-hosted, airship-build, gpu] needs a definition with gpu: set. One asking for arm64 needs an Arm instance type. One asking for windows needs a definition naming a Windows image — the Ubuntu aliases are Linux.
A job reads airship.yaml at its own commit. A definition added on main is not visible to a branch that has not merged it.
Idle runners cannot carry a run ID, so airship-build--${{ github.run_id }} never matches a pool runner. Drop the suffix on pooled labels.

Launch failures

Every cloud

AWS

Google Cloud

Azure

Runner states and finish reasons

On the machine itself

There is no inbound access, so reaching a machine means adding your own: your own security group and your own key, in your own image.

Still stuck

Three things worth confirming

  1. The repository is activated, not just granted to the app.
  2. The cloud named by the definition’s cloud: is connected and valid.
  3. The definition exists in airship.yaml at the commit the job ran from.
That triple covers most of what reaches support.