Skip to main content

Ausführen von Aufträgen auf größeren Runnern

Sie können Ihre Workflows beschleunigen, indem Sie sie so konfigurieren, dass sie auf größerer Runner ausgeführt werden.

Wer kann dieses Feature verwenden?

Größerer Runner sind nur für Organisationen und Unternehmen verfügbar, die GitHub Team- oder GitHub Enterprise Cloud-Tarife nutzen.

Platform navigation

Running jobs on your runner

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.

Note

Larger runners are automatically assigned a default label that corresponds to the runner name. You cannot add custom labels to larger runners, but you can use the default labels or the runner's group to send jobs to specific types of runners.

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.

Viewing available runners for a repository

If you have repo: write access to a repository, you can view a list of the runners available to the repository.

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

  2. Under your repository name, click Actions.

    Screenshot of the tabs for the "github/docs" repository. The "Actions" tab is highlighted with an orange outline.

  3. In the left sidebar, under the "Management" section, click Runners.

  4. Review the list of available runners for the repository.

  5. Optionally, to copy a runner's label to use it in a workflow, click to the right of the runner, then click Copy label.

Note

Enterprise and organization owners can create runners from this page. To create a new runner, click New runner at the top right of the list of runners to add runners to the repository.

For more information, see Managing larger runners and Adding self-hosted 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

Troubleshooting larger runners

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.