Provision a runner group in GitHub Actions
After you’ve learned the basics of GitHub Actions, you can begin to not only automate individual tasks, but also to create paved paths that help developers work more securely and efficiently. One way to do this is with runner groups, which give you the ability to specify which repositories and workflows can access certain runners. As we explore how you can use runner groups to improve the management, standardization, and scalability of your GitHub Actions, Stack Overflow will share how they use runner groups to “set it and forget it.”
In this guide, you will learn:
How runner groups function in GitHub Actions
What benefits runner groups offer
How runner groups can be used to create a paved path for developers
What are runner groups?
Enterprise and organization owners can use runner groups to control access to self-hosted runners and larger GitHub-hosted runners at the organization and/or enterprise levels. Runner groups collect sets of runners and create a security boundary around them, allowing you to decide which organizations or repositories are permitted to run jobs on those sets of machines. Policies then control which repositories in an organization have access to which runner group(s).
When you grant access to a runner group, you can see the runner group listed in the organization's runner settings. Optionally, you can assign additional granular repository and workflow access policies to the runner group. Newly-created runners are automatically assigned to the default group unless otherwise specified. Runners can only be in one group at a time, but you can easily move runners from one group to another.
Runner group access granularity
In GitHub Enterprise, runner groups can be created at either the enterprise or organization level. Depending on which you choose, access can then be further refined according to organization, repository, and workflow. Additional settings even allow restrictions based on branches, tags, or SHAs, ensuring that your infrastructure is both efficient and aligned with governance strategies.
What benefits do runner groups offer?
Runner groups in GitHub Actions provide several benefits for managing and organizing your runners:
Organization and management: Runner groups are used as a way to organize both self-hosted runners and GitHub-hosted runners in a repository, organization, or enterprise. This helps to manage and segment runners based on different project requirements or access levels.
Workflow targeting: You can better control where your workflows are executed by specifying specific runner groups in your workflow file. Access control: Runner groups can be used to manage access control. You can specify which repositories can use a runner group, providing an additional layer of security and control.
Parallelism and load distribution: By grouping runners, you can distribute the load between several machines, potentially speeding up your project's build and test processes.
Environment isolation: If your workflows require different environments, grouping runners that provide those environments can simplify workflow setup.
Actions runner groups are a way to 'set it and forget it,' and allow your team to concentrate on other high-priority tasks. Runner groups have substantially eased the complexities of managing access to runners and they offer the flexibility to reallocate resources as your project needs evolve. They let you define which users, repositories, and projects have access to runners in specialized network contexts, like different Azure tenants.
Using runner groups to create paved paths
The use of runner groups can make GitHub Actions easier and more reliable to use, making it a smoother experience for developers. Runner groups in GitHub Actions can provide a "paved path" for developers in several ways:
Standardization: By setting up specific runner groups for different types of workflows (for example, based on language or platform), you can ensure that all workflows of a certain type use the same environment. This reduces the likelihood of "it works on my machine" issues.
Security: Runner groups can be restricted to specific repositories, preventing unauthorized access to self-hosted runners. This can be particularly important if your runners have access to sensitive resources.
Efficiency: If you have workloads that require specific resources, creating runner groups with the necessary hardware or software can ensure that these workflows always have access to the resources they need.
Simplicity: Developers just need to specify the runner group in their workflow file, and the appropriate runner will be used. They don't need to worry about the details of the runner setup.
Scalability: Runner groups can be scaled up by adding more runners to the group, allowing you to handle increasing workloads without changing your workflow files.
Runner groups are a cornerstone in GitHub's automation tools. Their ability to optimize resource allocation ensures smooth and secure scalability across repositories. Combined with reusable workflows, which we will talk about next, you will be well on your way to creating that paved path to increase security, resource control, and developer efficiency.
Up next: Create reusable workflows in GitHub Actions
Our next guide dives into reusable workflows, teaching you how to standardize processes, avoid redundancy, and achieve peak efficiency across your projects.