Skip to main content

より大きなランナーでジョブを実行する

ワークフローをより大きなランナーで実行するように構成することで、ワークフローを高速化できます。

この機能を使用できるユーザーについて

より大きなランナー は、GitHub Team または GitHub Enterprise Cloud プランを使っている組織とエンタープライズのみが使用できます。

Platform navigation

ランナーでのジョブの実行

ランナーの種類が定義されたら、ワークフローの YAML ファイルを更新し、処理のために新しく作成されたランナー インスタンスにジョブを送信できます。 ランナー グループまたはラベルを使用して、ジョブが実行される場所を定義することができます。

注: より大きなランナー には、ランナー名に対応する既定のラベルが自動的に割り当てられます。 より大きなランナーにはカスタム ラベルは追加できませんが、既定のラベルまたはランナーのグループを使って、特定の種類のランナーにジョブを送信できます。

ランナーの設定を表示できるのは、所有者または管理者アカウントのみです。 管理者以外のユーザーは組織のオーナーに連絡すると、有効になっているランナーを確認できます。 組織のオーナーは、新しいランナーとランナー グループを作成したり、ランナー グループにアクセスできるリポジトリを指定するためのアクセス許可を構成したりできます。 詳しくは、「より大きなランナーを管理する」を参照してください。

ランナーの種類が定義されたら、ワークフローの YAML ファイルを更新し、処理のために新しく作成されたランナー インスタンスにジョブを送信できます。 ランナー グループまたはラベルを使用して、ジョブが実行される場所を定義することができます。

注: より大きなランナー には、ランナー名に対応する既定のラベルが自動的に割り当てられます。 より大きなランナーにはカスタム ラベルは追加できませんが、既定のラベルまたはランナーのグループを使って、特定の種類のランナーにジョブを送信できます。

ランナーの設定を表示できるのは、所有者または管理者アカウントのみです。 管理者以外のユーザーは組織のオーナーに連絡すると、有効になっているランナーを確認できます。 組織のオーナーは、新しいランナーとランナー グループを作成したり、ランナー グループにアクセスできるリポジトリを指定するためのアクセス許可を構成したりできます。 詳しくは、「より大きなランナーを管理する」を参照してください。

ランナーの種類が定義されたら、ワークフローの YAML ファイルを更新し、処理のためにランナー インスタンスにジョブを送信できます。 macOS より大きなランナーs でジョブを実行するには、ワークフロー YAML ファイルの runs-on キーを更新して、macOS ランナーの GitHub 定義ラベルのいずれかを使用します。 詳しくは、「使用可能な macOS より大きなランナー」をご覧ください。

使用可能な macOS より大きなランナーs

次の表のラベルを使用して、対応する macOS より大きなランナー でワークフローを実行します。

ランナー サイズArchitectureプロセッサ (CPU)メモリ(RAM)ストレージ (SSD)ワークフロー ラベル
LargeIntel1230 GB14 GBmacos-latest-largemacos-12-largemacos-13-largemacos-14-large[最新」、macos-15-large[パブリック プレビュー]
XLargearm64 (M1)6 (+ 8 GPU ハードウェア アクセラレータ)14 GB14 GBmacos-latest-xlargemacos-13-xlargemacos-14-xlarge[最新」、macos-15-xlarge[パブリック プレビュー]

注: macOS より大きなランナー s の場合、 -latest ランナー ラベルは macOS 12 ランナー イメージを使用します。 macOS Xlarge の場合、 -latest ランナー ラベルは macOS 13 ランナーイメージを使用します

リポジトリで使用可能なランナーの表示

リポジトリに repo: write アクセス許可を持つ場合は、リポジトリで使用できるランナーの一覧が表示されます。

  1. GitHub で、リポジトリのメイン ページに移動します。

  2. リポジトリ名の下にある [アクション] をクリックします。

    "github/docs" リポジトリのタブのスクリーンショット。 [アクション] タブがオレンジ色の枠線で強調表示されています。

  3. 左サイドバーの [管理] セクションで、[ランナー] をクリックします。

  4. リポジトリで使用可能なランナーの一覧を確認します。

  5. 必要に応じて、ランナーのラベルをコピーしてワークフローで使用するには、ランナーの右側にある をクリックし、[ラベルのコピー] をクリックします。

注: Enterprise オーナーと Organization オーナーは、このページからランナーを作成できます。 新しいランナーを作成するには、ランナーの一覧の右上にある [新しいランナー] をクリックして、リポジトリにランナーを追加します。

詳細は、「より大きなランナーを管理する」または「自己ホストランナーの追加」を参照してください。

グループを使用してジョブの実行場所を制御する

この例では、Ubuntu ランナーが ubuntu-runners というグループに追加されています。 runs-on キーは、ubuntu-runners グループ内の使用可能なランナーにジョブを送信します。

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

グループを使用してジョブの実行場所を制御する

この例では、Ubuntu ランナーが ubuntu-runners というグループに追加されています。 runs-on キーは、ubuntu-runners グループ内の使用可能なランナーにジョブを送信します。

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

ラベルを使用してジョブの実行場所を制御する

構文 runs-on: LABEL を使用して、runs-on キーにラベルを暗黙的に渡すことができます。 または、次の例に示すように、labels キーを使用することもできます。

この例では、runs-on キーは、ubuntu-20.04-16core ラベルが割り当てられている使用可能なランナーにジョブを送信します。

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

アクションが有効なリポジトリへの書き込みアクセス権限を持つすべてのユーザーは、そのリポジトリで使用可能なランナーのラベルを確認できます。 「より大きなランナーでジョブを実行する」をご覧ください。

ラベルを使用してジョブの実行場所を制御する

構文 runs-on: LABEL を使用して、runs-on キーにラベルを暗黙的に渡すことができます。 または、次の例に示すように、labels キーを使用することもできます。

この例では、runs-on キーは、windows-2022-16core ラベルが割り当てられている使用可能なランナーにジョブを送信します。

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

アクションが有効なリポジトリへの書き込みアクセス権限を持つすべてのユーザーは、そのリポジトリで使用可能なランナーのラベルを確認できます。 「より大きなランナーでジョブを実行する」をご覧ください。

ワークフロー内の macOS より大きなランナーs を対象とする

macOS より大きなランナー でワークフローを実行するには、runs-on キーの値を macOS より大きなランナー に関連付けられているラベルに設定します。 macOS より大きなランナー ラベルの一覧については、「使用可能な macOS より大きなランナー」を参照してください。

この例では、ワークフローは macOS XL ランナーに関連付けられているラベルを使用します。 runs-on キーは、一致するラベルを持つ使用可能なランナーにジョブを送信します。

name: learn-github-actions-testing
on: [push]
jobs:
  build:
    runs-on: macos-13-xlarge
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: swift build
      - name: Run tests
        run: swift test

ラベルとグループを使用してジョブの実行場所を制御する

グループとラベルを組み合わせる場合、ランナーはジョブを実行する資格を得るために両方の要件を満たす必要があります。

この例では、ubuntu-runners というランナー グループに、ラベル ubuntu-20.04-16core も割り当てられている Ubuntu ランナーが設定されています。 runs-on キーは grouplabels を組み合わせて、ラベルが一致するグループ内の使用可能な任意のランナーにジョブがルーティングされるようにします。

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

ラベルとグループを使用してジョブの実行場所を制御する

グループとラベルを組み合わせる場合、ランナーはジョブを実行する資格を得るために両方の要件を満たす必要があります。

この例では、ubuntu-runners というランナー グループに、ラベル ubuntu-20.04-16core も割り当てられている Ubuntu ランナーが設定されています。 runs-on キーは grouplabels を組み合わせて、ラベルが一致するグループ内の使用可能な任意のランナーにジョブがルーティングされるようにします。

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

より大きなランナーのトラブルシューティング

より大きなランナーをターゲットとするジョブが遅延している、または実行されていない場合は、いくつかの要因が考えられます。

  • コンカレンシー設定: コンカレンシーが上限に達している可能性があります。 より多くのジョブを並列で実行できるようにする場合は、自動スケーリング設定をより大きな数値に更新します。 詳しくは、「より大きなランナーを管理する」を参照してください。
  • リポジトリ アクセス許可: より大きなランナーに対して適切なリポジトリ アクセス許可が有効になっていることを確認します。 既定で、エンタープライズ ランナーはリポジトリ レベルでは使用できないため、組織管理者が手動で有効にする必要があります。 詳しくは、「より大きなランナーを管理する」を参照してください。
  • 課金: より大きなランナーを使うには、有効なクレジット カードを登録する必要があります。 アカウントにクレジット カードを追加してから、より大きなランナーの使用が有効になるまでに最長 10 分かかる場合があります。 詳しくは、「支払い方法を追加または編集する」を参照してください。
  • 使用制限: GitHub Actionsの使用制限を 0 より大きい値に設定する必要があります。 詳しくは、「GitHub Actions の使用制限の管理」を参照してください。
  • フェア ユース ポリシー: GitHubには、実行しているジョブ数やGitHub Actions全体で実行されているジョブ数など、いくつかの要因に基づいてジョブの調整を開始するフェア ユース ポリシーがあります。
  • ジョブ キューに入ってから割り当てるまでの時間: ジョブ キューに入ってから割り当てるまでの時間とは、ジョブ要求を受信してから、GitHub がそのジョブを実行する VM を割り当てるまでの時間を指します。 所定の YAML ワークフロー ラベル (ubuntu-latest など) を使用している標準の GitHub ホスト ランナーは、常に "ウォーム" 状態になります。 より大きなランナーを使用した場合、ウォーム マシンでは、(マシンのプールが小さいために) 最初の要求を受信した時にジョブを取得する準備ができていない可能性があります。 その結果、GitHub は新しい VM を作成する必要があるため、キューに入ってから割り当てるまでの時間が長くなります。 一度ランナーが使用されると、VM は後続のワークフロー実行にすぐに対応し、その後 24 時間のワークフロー実行において、キューに入ってから割り当てるまでの時間が短縮されます。

より大きなランナーをターゲットとするジョブが遅延している、または実行されていない場合は、いくつかの要因が考えられます。

  • コンカレンシー設定: コンカレンシーが上限に達している可能性があります。 より多くのジョブを並列で実行できるようにする場合は、自動スケーリング設定をより大きな数値に更新します。 詳しくは、「より大きなランナーを管理する」を参照してください。
  • リポジトリ アクセス許可: より大きなランナーに対して適切なリポジトリ アクセス許可が有効になっていることを確認します。 既定で、エンタープライズ ランナーはリポジトリ レベルでは使用できないため、組織管理者が手動で有効にする必要があります。 詳しくは、「より大きなランナーを管理する」を参照してください。
  • 課金: より大きなランナーを使うには、有効なクレジット カードを登録する必要があります。 アカウントにクレジット カードを追加してから、より大きなランナーの使用が有効になるまでに最長 10 分かかる場合があります。 詳しくは、「支払い方法を追加または編集する」を参照してください。
  • 使用制限: GitHub Actionsの使用制限を 0 より大きい値に設定する必要があります。 詳しくは、「GitHub Actions の使用制限の管理」を参照してください。
  • フェア ユース ポリシー: GitHubには、実行しているジョブ数やGitHub Actions全体で実行されているジョブ数など、いくつかの要因に基づいてジョブの調整を開始するフェア ユース ポリシーがあります。
  • ジョブ キューに入ってから割り当てるまでの時間: ジョブ キューに入ってから割り当てるまでの時間とは、ジョブ要求を受信してから、GitHub がそのジョブを実行する VM を割り当てるまでの時間を指します。 所定の YAML ワークフロー ラベル (ubuntu-latest など) を使用している標準の GitHub ホスト ランナーは、常に "ウォーム" 状態になります。 より大きなランナーを使用した場合、ウォーム マシンでは、(マシンのプールが小さいために) 最初の要求を受信した時にジョブを取得する準備ができていない可能性があります。 その結果、GitHub は新しい VM を作成する必要があるため、キューに入ってから割り当てるまでの時間が長くなります。 一度ランナーが使用されると、VM は後続のワークフロー実行にすぐに対応し、その後 24 時間のワークフロー実行において、キューに入ってから割り当てるまでの時間が短縮されます。

macOS arm64 は Node 12 をサポートしていないため、macOS より大きなランナー はノード 16 を自動的に使用して、Node 12 用に記述された JavaScript アクションを実行します。 一部のコミュニティ アクションは、Node 16 と互換性がない場合があります。 別の Node バージョンを必要とするアクションを使用する場合は、実行時に特定のバージョンを手動でインストールすることが必要になる場合があります。

注: ARM 搭載ランナーは現在 パブリック プレビュー にあり、変更される可能性があります。