Running jobs on larger runners

Once your runner type has been defined, you can update your workflow YAML files to send jobs to your newly created runner instances for processing. You can use runner groups or labels to define where your jobs run.

Only owner or administrator accounts can see the runner settings. Non-administrative users can contact the organization owner to find out which runners are enabled. Your organization owner 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 "Managing larger runners."

Using groups to control where jobs are run

In this example, Ubuntu runners have been added to a group called ubuntu-runners. The runs-on key sends the job to any available runner in the ubuntu-runners group:

name: learn-github-actions
on: [push]
jobs:
  check-bats-version:
    runs-on: 
      group: ubuntu-runners
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

Using labels to control where jobs are run

You can implicitly pass a label to the runs-on key by using the syntax runs-on: LABEL. Alternatively, you can use the labels key, as shown in the example below.

In this example, the runs-on key sends the job to any available runner that has been assigned the ubuntu-20.04-16core label:

name: learn-github-actions
on: [push]
jobs:
  check-bats-version:
    runs-on:
      labels: ubuntu-20.04-16core
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

Anyone with write access to an Actions-enabled repository can find out the labels for the runners that are available in that repository. See "Running jobs on larger runners."

Using labels and groups to control where jobs are run

When you combine groups and labels, the runner must meet both requirements to be eligible to run the job.

In this example, a runner group called ubuntu-runners is populated with Ubuntu runners, which have also been assigned the label ubuntu-20.04-16core. The runs-on key combines group and labels so that the job is routed to any available runner within the group that also has a matching label:

name: learn-github-actions
on: [push]
jobs:
  check-bats-version:
    runs-on:
      group: ubuntu-runners
      labels: ubuntu-20.04-16core
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

Using unique names for runner groups

GitHub Actions requires that runner group names must be unique at the organization level. This means that an organization will no longer be able to create a runner group with the same name as one in the enterprise. In addition, users will see a warning banner on any runner groups that share the same name as a group in the enterprise, suggesting that the organization group should be renamed.

To avoid ambiguity, a workflow will fail if there are duplicate runner groups in the organization and enterprise. To address this, you can either rename one of your runner groups in the organization or enterprise, or you can update your workflow file to add a prefix to the runner group name:

• org/ or organization/
• ent/ or enterprise/

Example: Using prefixes to differentiate runner groups

For example, if you have a runner group named my-group in the organization and another named my-group in the enterprise, you can update your workflow file to use org/my-group or ent/my-group to differentiate between the two.

Using org/:

runs-on:
  group: org/my-group
  labels: [ self-hosted, label-1 ]

Using ent/:

runs-on:
  group: ent/my-group
  labels: [ self-hosted, label-1 ]

If you notice the jobs that target your larger runners are delayed or not running, there are several factors that may be causing this.

• Concurrency settings: You may have reached your maximum concurrency limit. If you would like to enable more jobs to run in parallel, you can update your autoscaling settings to a larger number. For more information, see "Managing larger runners."
• Repository permissions: Ensure you have the appropriate repository permissions enabled for your larger runners. By default, enterprise runners are not available at the repository level and must be manually enabled by an organization administrator. For more information, see "Managing larger runners."
• Billing information: You must have a valid credit card on file in order to use larger runners. After adding a credit card to your account, it can take up to 10 minutes to enable the use of your larger runners. For more information, see "Adding or editing a payment method."
• Spending limit: Your GitHub Actions spending limit must be set to a value greater than zero. For more information, see "Managing your spending limit for GitHub Actions."
• Fair use policy: GitHub has a fair use policy that begins to throttle jobs based on several factors, such as how many jobs you are running or how many jobs are running across the entirety of GitHub Actions.
• Job queue to assign time: Job queue to assign time refers to the time between a job request and GitHub assigning a VM to execute the job. Standard GitHub-hosted runners utilizing prescribed YAML workflow labels (such as ubuntu-latest) are always in a "warm" state. With larger runners, a warm machine may not be ready to pick up a job on first request as the pools for these machines are smaller. As a result, GitHub may need to create a new VM, which increases the queue to assign time. Once a runner is in use, VMs are readily for subsequent workflow runs, reducing the queue to assign time for future workflow runs over the next 24 hours.