Self-hosted runners are not visible to GitHub Actions workflows in public repositories by default: "No runner matching the specified labels was found:"

Posting this here so the problem and resolution are googleable.

I’ve created a public template repository in an organization and configured a self-hosted runner for that organization. I then created a very simple workflow in that repository with runs-on: self-hosted.

Unfortunately, the workflow failed with the following error message:

No runner matching the specified labels was found: self-hosted.

However, both the repository’s and the organization’s settings displayed that the runner is available and tagged with self-hosted. In the repository’s settings, it’s displayed in the “Runners shared with this repository” section:

As it turns out, not only GitHub Actions warns that using self-hosted runners in public repositories is dangerous, it’s actually disabled by default.

If you go to organization’s settings, there is an ellipsis next to each runner group. It gets you to a group edit dialog, which has the “Allow public repositories” checkbox, unchecked by default.

Unfortunately, it looks like it only means that a runner in such group is not visible to GitHub Actions workflow in the repository (which causes the “no runner … was found” error), but is still visible in settings with no indication.

Hopefully, a clearer error message or some indication in repository’s settings will be added at some point.

So, the solution is:

  1. Think really hard whether you really want to enable self-hosted runner on a public repository. Probably you don’t because any malicious actor can fork the repo and send pull request with an arbitrary code to be executed on your server. Note that the self-hosted runner provides very little (if any) security by default, as far as I can tell.
  2. Think again. Maybe disable pull requests altogether (not sure if PRs are the only attack vector, though).
  3. Check the checkbox mentioned in the original post.

@yeputons,

Thanks for your feedback.
I can reproduce the same problem.

I have created an issue ticket (actions/runner#758) to report the problem to the appropriate engineering team for further investigation and evaluation.

You can follow this issue ticket and add your comments to it.

1 Like