Running jobs
Workflows
The routing line#
A job's runs-on reads a repository variable, BUILDHOUND_MACOS or BUILDHOUND_LINUX, with GitHub's hosted label as the default:
runs-on: ${{ vars.BUILDHOUND_MACOS || 'macos-latest' }}The control plane writes the variable when a machine can take jobs for that label and clears it when none can. Your workflow never changes again; where the job runs follows your machines.
Public repositories#
On a public repository anyone on GitHub can open a pull request from a fork, comment on an issue or start a discussion, and each of those can start a workflow. Use the longer expression. It sends a job to your machine only for a push, a schedule, a manual run, the merge queue, a release, or a pull request from a branch of the repository itself. Everything else stays on GitHub-hosted, whatever the variable says:
runs-on: ${{ ((github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository) || github.event_name == 'push' || github.event_name == 'schedule' || github.event_name == 'workflow_dispatch' || github.event_name == 'merge_group' || github.event_name == 'release') && vars.BUILDHOUND_MACOS || 'macos-latest' }}A pull request whose fork was deleted, pull_request_target, workflow_run and comment events all stay on GitHub-hosted. npx buildhound route --repo owner/name gives the line to write for each job and lists any routed job on a public repository that still uses an older expression, with the change to make.
Several jobs and machines#
Every machine on the account registers under the shared label, so a matrix fans out across whichever machines have room. A machine runs one macOS job at a time, plus as many 4 GB Linux jobs as its memory holds; laptops run one job at a time. Jobs that use secrets run only on machines marked as trusted (Security).