An organisation has self-hosted runners on two operating systems registered in one runner group that is available to all repositories. A workflow job must run only on the runners backed by graphics processing units, which carry a custom gpu label, while still being a self-hosted runner. How should the job target those machines?
jobs:
train:
runs-on: <target>- ASet runs-on to gpu-latest, because GitHub resolves the suffix to the newest self-hosted runner in the group that has been tagged with the gpu capability label.
- BSet runs-on to a combined array of [self-hosted, gpu], because the job is then dispatched only to a self-hosted runner that also carries the gpu label rather than any available machine. Correct
- CSet runs-on to gpu alone and rely on the runner group restriction, because membership of the group already guarantees that only graphics machines accept the job.
- DSet runs-on to self-hosted and move the gpu requirement into a separate runner-group key on the job, because the group key filters runners by hardware capability label.
Why A is wrong: Tempting because version-style suffixes appear in runner labels, but a latest suffix is not how self-hosted labels resolve. There is no automatic newest-runner selection, and the value would simply fail to match any registered label.
Why B is correct: Listing multiple labels in the runs-on array requires a runner to match every label, so [self-hosted, gpu] selects only self-hosted machines that also advertise the gpu label, which is exactly the targeting required.
Why C is wrong: Tempting because the gpu label does point at the right machines, but omitting self-hosted is less precise and the group contains mixed runners, so the group membership alone does not guarantee a graphics machine receives the job.
Why D is wrong: Tempting because runner groups exist, but there is no job-level runner-group key that filters by label. Self-hosted runner targeting by capability is expressed entirely through the labels listed in runs-on.