This chapter covers
- Managing runner groups
- Monitoring your runners
- Finding runner utilization and capacity needs
- Internal billing for action usage
When you start creating your self-hosted runners, you will need to find out how and when your runners are being utilized, by which repositories and teams. With that information you can then both scale the runners appropriately and guide your users into better patterns of using them. There are options to segment runners into groups and only allow a group to be used by specific repositories (e.g., by a single team).
7.1 Runner groups
With runner groups, you can segment your runners into different clusters and manage access to the runners in the group with specific options. You can use runner groups, for example, to segment the runners for the repos of a specific team and make sure they always have a specific number of runners available. Or you can use them to make sure a group of runners with a certain capability (e.g., GPU-enabled runners) are only available to certain repositories and, thus, users. You do not want to run simple linting jobs on those expensive runners, so you better make sure to separate these runners from the default runners that have the self-hosted label!