Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://docs.github.com/en/actions/using-github-hosted-runners/controlling-access-to-larger-runners below:

Controlling access to larger runners

You can use policies to limit access to larger runners that have been added to an organization or enterprise.

Larger runners are only available for organizations and enterprises using the GitHub Team or GitHub Enterprise Cloud plans.

Note

The information and instructions in this article only apply to larger runners with Linux and Windows operating systems.

Note

Before your workflows can send jobs to larger runners, you must first configure permissions for the runner group. See the following sections for more information.

Runner groups are used to control which repositories can run jobs on your larger runners. You must manage access to the group from each level of the management hierarchy, depending on where you've defined the larger runner:

• Runners at the enterprise level: By default, repositories in an organization do not have access to enterprise-level runner groups. To give repositories access to enterprise runner groups, organization owners must configure each enterprise runner group and choose which repositories have access.
• Runners at the organization level: By default, all repositories in an organization are granted access to organization-level runner groups. To restrict which repositories have access, organization owners must configure organization runner groups and choose which repositories have access.

For example, the following diagram has a runner group named grp-ubuntu-20.04-16core at the enterprise level. Before the repository named octo-repo can use the runners in the group, you must first configure the group at the enterprise level to allow access to the octo-org organization. You must then configure the group at the organization level to allow access to octo-repo.

Warning

If you are using a Fixed IP range, we recommend that you only use larger runners with private repositories. Forks of your repository can potentially run dangerous code on your larger runner by creating a pull request that executes the code in a workflow.

Note

When creating a runner group, you must choose a policy that defines which repositories have access to the runner group. To change which repositories and workflows can access the runner group, organization owners can set a policy for the organization. For more information, see Enforcing policies for GitHub Actions in your enterprise.

All organizations have a single default runner group. Organization owners using the GitHub Team plan can create additional organization-level runner groups.

If no group is specified during the registration process, runners are automatically added to the default group. You can later move the runner from the default group to a custom group.

For information about how to create a runner group with the REST API, see REST API endpoints for GitHub Actions.

1. On GitHub, navigate to the main page of the organization.

2. Under your organization name, click Settings. If you cannot see the "Settings" tab, select the dropdown menu, then click Settings.

3. In the left sidebar, click Actions, then click Runner groups.

4. In the "Runner groups" section, click New runner group.

5. Enter a name for your runner group.

6. Assign a policy for repository access.

   You can configure a runner group to be accessible to a specific list of repositories, or to all repositories in the organization. By default, only private repositories can access runners in a runner group, but you can override this. This setting can't be overridden if configuring an organization's runner group that was shared by an enterprise.

7. Click Create group to create the group and apply the policy.

Warning

If you are using a Fixed IP range, we recommend that you only use larger runners with private repositories. Forks of your repository can potentially run dangerous code on your larger runner by creating a pull request that executes the code in a workflow.

For runner groups in an organization, you can change what repositories in the organization can access a runner group.

1. Navigate to the main page of the organization where your runner groups are located.

2. Click Settings.

3. In the left sidebar, click Actions, then click Runner groups.

4. In the list of groups, click the runner group you'd like to configure.

5. Under "Repository access," use the dropdown menu to click Selected repositories.

   1. To the right of the dropdown menu, click .
   2. In the popup, use the checkboxes to select repositories that can access this runner group.

6. Click Save group.

You can use GitHub-hosted runners in an Azure VNET. This enables you to use GitHub-managed infrastructure for CI/CD while providing you with full control over the networking policies of your runners. For more information about Azure VNET, see What is Azure Virtual Network? in the Azure documentation.

If you have configured your organization to connect to an Azure VNET, you can give runner groups access to the virtual network. For more information, see Private networking with GitHub-hosted runners.

1. Navigate to the main page of the organization where your runner groups are located.
2. Click Settings.
3. In the left sidebar, click Actions, then click Runner groups.
4. In the list of groups, click the runner group you'd like to configure.
5. Enter the new runner group name in the text field under "Group name."
6. Click Save.

If you don't specify a runner group during the registration process, your new runners are automatically assigned to the default group, and can then be moved to another group.

1. On GitHub, navigate to the main page of the organization.

2. Under your organization name, click Settings. If you cannot see the "Settings" tab, select the dropdown menu, then click Settings.

3. In the left sidebar, click Actions, then click Runners.

4. In the "Runners" list, click the runner that you want to configure.

5. Select the Runner group drop-down.

6. In "Move runner to group", choose a destination group for the runner.

In order to remove a runner group, you must first move or remove all of the runners from the group.

1. Navigate to the main page of the organization where your runner groups are located.
2. Click Settings.
3. In the left sidebar, click Actions, then click Runner groups.
4. In the list of groups, to the right of the group you want to delete, click .
5. To remove the group, click Remove group.
6. Review the confirmation prompts, and click Remove this runner group.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4