Prevent jobs from running on a self-hosted runner unless tag specified?

Our organization has 1000+ repos and many are configured to use Actions. We have a few self-hosted runners with very specific use cases and have tags (tag:GPU) that differentiate these runners from the generic runners that can run anything.

Is there any way to ONLY run actions if the GPU tag is specified in the workflow? It appears that if only the GPU runners are available, then any workflow of the same OS will run on it whereas we want to actively prevent workflows from running if it doesn’t specify this tag.

Example:
Workflow.yml #1:

runs-on: [self-hosted, GPU]

Workflow.yml #2:

runs-on: [self-hosted]

We don’t want workflow.yml #2 to ever run on a runner configured with the tag GPU.

Hi @nick-invision,

‘self-hosted’ label is a common label for self-hosted runners, it’s added automatically when runner is created.
Github job will matach all self-hosted runners with the label specified, if you only add label ‘self-hosted’, it will match all self-hosted runners.
Hence, as a workaround, you can add different labels to NON-GPU runners, and sepecify more labels in yaml2 to exactly match the runners.

For example of yaml2:

runs-on: [self-hosted, NONGPU]   # add NONGPU label to the other runners.

Thanks.

Thanks, that was considered however with many repos and runners, adding a generic label to existing workflows and agents isn’t trivial and ensuring future workflows and agents include the generic label is also difficult to enforce considering most users just follow the documentation.

I want to enter an issue against the most relevant repo to track this. Can you specify whether this should go into the actions/runner repo or a different one?

Greetings!

We are working on a feature called “runner groups” which will let you determine visibility of groups of various self hosted runners to repos/orgs. I think this is exactly what you want. We hope to ship it by mid-end summer (I’ll be vague with timelines until we get further :smile:)

You can’t do it yet, though.

For example you can see this open issue as it relates to setting runner groups at config time: https://github.com/actions/runner/issues/517

1 Like

Yes! That is exactly what we need. We have a group repos that would need access to these specific runners and no others. I’ll wait patiently until then :grinning:

1 Like