Blacksmith Jobs Queue When the GitHub App Is Not Installed
Blacksmith watches and provisions capacity only for repositories where its GitHub App is installed. Miss one, and jobs can queue or quietly consume capacity meant for another repo.
According to Blacksmith's runner docs, Blacksmith only watches and provisions capacity for repositories where the app is installed. If repo foo has Blacksmith installed but bar and baz also use runs-on: blacksmith-*, the runners provisioned for foo can end up adopting jobs from bar or baz, which under-provisions everyone.
The documented fix
Blacksmith's docs are explicit: install the Blacksmith GitHub App on every repository that uses runs-on: blacksmith-* to prevent this. If any repo references the labels without the app installed, expect queuing and capacity contention.
How to audit
- Grep your org for runs-on: blacksmith-* across all repos and workflows.
- Cross-check that list against the repos where the Blacksmith GitHub App is installed.
- Install the app on any repo that uses the labels but is missing it.
Where a managed alternative differs
Latchkey also attaches to GitHub Actions and provisions managed runners, so app or org access setup matters there too. The difference Latchkey adds is downstream: once a job is running, transient and mechanical failures self-heal and retry automatically instead of leaving you to re-run red builds.
If you want failures to recover on their own
Blacksmith is a strong choice when raw runner speed and per-core performance are your priority. If your recurring pain is instead flaky, transient failures that force manual re-runs, Latchkey is worth a look: it runs your GitHub Actions on managed, drop-in runners and adds self-healing CI, so out-of-memory kills, disk-full errors, and registry timeouts are detected and retried automatically. You can pilot it on a single workflow with a one-line runs-on change and compare against your real builds.