Commit 20b78c8

Enterprise owners can add {% data variables.actions.hosted_runner %}s to an enterprise and assign them to organizations. By default, when a {% data variables.actions.hosted_runner %} is created for an enterprise, it is added to a default runner group that all organizations in the enterprise have access to. While all organizations are granted access to the runner, the repositories in each organization **are not** granted access. For each organization, an organization administrator must configure the runner group to specify which repositories have access to the enterprise runner. For more information, see "[Allowing repositories to access a runner group](#allowing-repositories-to-access-a-runner-group)."

You can add a {% data variables.actions.hosted_runner %} to an organization, where organization administrators can control which repositories can use it. When you create a new runner for an organization, by default, all repositories in the organization have access to the runner. To limit which repositories can use the runner, assign it to a runner group with access to specific repositories. For more information, see "[Allowing repositories to access a runner group](#allowing-repositories-to-access-a-runner-group)."

Repositories are granted access to {% data variables.actions.hosted_runner %}s through runner groups. Enterprise administrators can choose which organizations are granted access to enterprise-level runner groups, and organization administrators control repository-level access to all {% data variables.actions.hosted_runner %}s. Organization administrators can use and configure enterprise-level runner groups for the repositories in their organization, or they can create organization-level runner groups to control access.

Only owner or administrator accounts can see the runner settings. Non-administrative users can contact the organization administrator to find out which runners are enabled. Your organization administrator can create new runners and runner groups, as well as configure permissions to specify which repositories can access a runner group. For more information, see "[AUTOTITLE](/actions/using-github-hosted-runners/managing-larger-runners#allowing-repositories-to-access-a-runner-group)."

{% note %}

**Note:** A job that is skipped will report its status as "Success". It will not prevent a pull request from merging, even if it is a required check.

{% endnote %}

Organization admins can add their self-hosted runners to groups, and then create policies that control which repositories can access the group.

By default, repositories in an organization do not have access to enterprise-level runner groups. To give repositories access to enterprise runner groups, organization administrators must configure each enterprise runner group and choose which repositories have access.

By default, all repositories in an organization are granted access to organization-level runner groups. To restrict which repositories have access, organization administrators must configure organization runner groups and choose which repositories have access.

To control access to runners at the organization{% ifversion ghec or ghes or ghae %} and/or enterprise levels, enterprise and organization administrators can use runner groups.{% else %} level, organizations using the {% data variables.product.prodname_team %} plan can use runner groups. {% endif %}

{%- ifversion ghec or ghes or ghae %} Enterprise administrators can configure access policies that control which organizations {% ifversion restrict-groups-to-workflows %}and workflows {% endif %}in an enterprise have access to the runner group.{% else %} Organization administrators can configure access policies that control which repositories in an organization have access to the runner group.{% endif %}