GitHub ホステッド ランナーの概要
ランナーは、GitHub Actions ワークフローでジョブを実行するマシンです。 たとえば、ランナーはリポジトリをローカルにクローンし、テスト ソフトウェアをインストールしてから、コードを評価するコマンドを実行できます。
GitHub は、ジョブの実行に使用できるランナーを提供します。または、独自のランナーをホストすることもできます。 各 GitHub ホステッド ランナーは、ランナー アプリケーションとその他のツールがプレインストールされた GitHub によってホストされる新しい仮想マシン (VM) であり、Ubuntu Linux、Windows、または macOS オペレーティング システムで使用できます。 GitHubホストランナーを使用すると、マシンのメンテナンスとアップグレードが自動的に行われます。
GitHub ホステッド ランナーの使用
GitHub ホステッド ランナーを使用するには、ジョブを作成し、runs-on を使用してジョブを処理するランナーの種類を指定します (例: ubuntu-latest、windows-latest、または macos-latest)。 ランナーの種類の完全な一覧については、「サポートされているランナーとハードウェア リソース」を参照してください。
ジョブが開始されると、GitHub によって、そのジョブの新しい VM が自動的にプロビジョニングされます。 ジョブ中のすべてのステップは VM で実行されるため、ランナーのファイルシステムを使用して、そのジョブにおけるステップで情報を共有することができます。 ワークフローは、VM で直接実行することも、Docker コンテナーで実行することもできます。 ジョブが完了すると、VM は自動的に使用停止になります。
次のダイアグラムは、2 つの異なる GitHub ホステッド ランナーでワークフロー内の 2 つのジョブがどのように実行されるかを示しています。

次のワークフロー例には、Run-npm-on-Ubuntu および Run-PSScriptAnalyzer-on-Windows という名前のついた 2 つのジョブがあります。 このワークフローがトリガーされると、GitHub ではジョブごとに新しい仮想マシンをプロビジョニングします。
Run-npm-on-Ubuntuという名前のジョブは Linux VM で実行されます。これは、ジョブのruns-on:でubuntu-latestが指定されているためです。Run-PSScriptAnalyzer-on-Windowsという名前のジョブは Windows VM で実行されます。これは、ジョブのruns-on:でwindows-latestが指定されているためです。
name: Run commands on different operating systems
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
Run-npm-on-Ubuntu:
name: Run npm on Ubuntu
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: '14'
- run: npm help
Run-PSScriptAnalyzer-on-Windows:
name: Run PSScriptAnalyzer on Windows
runs-on: windows-latest
steps:
- uses: actions/checkout@v3
- name: Install PSScriptAnalyzer module
shell: pwsh
run: |
Set-PSRepository PSGallery -InstallationPolicy Trusted
Install-Module PSScriptAnalyzer -ErrorAction Stop
- name: Get list of rules
shell: pwsh
run: |
Get-ScriptAnalyzerRuleジョブの実行中、ログと出力は GitHub UI で表示できます。

GitHub Actionsランナーアプリケーションはオープンソースです。 ランナー リポジトリでイシューを投稿およびファイルできます。
サポートされているランナーとハードウェアリソース
メモ: GitHub には、より大きな構成で使うことができる より大きなランナー も用意されています。 詳しくは、「より大きなランナー のマシン スペック」をご覧ください。
Windows および Linux 仮想マシンのハードウェア仕様:
- 2 コア CPU (x86_64)
- 7 GB の RAM
- 14 GB の SSD 領域
macOS 仮想マシンのハードウェア仕様:
- 3 コア CPU (x86_64)
- 14 GB の RAM
- 14 GB の SSD 領域
| ランナー イメージ | YAML ワークフロー ラベル | メモ |
|---|---|---|
| Windows Server 2022 |
windows-latest または windows-2022
|
windows-latest ラベルは現在、Windows Server 2022 ランナー イメージを使用しています。
|
| Windows Server 2019 |
windows-2019
|
|
| Ubuntu 22.04 |
ubuntu-latest または ubuntu-22.04
|
ubuntu-latest ラベルは現在、Ubuntu 22.04 ランナー イメージを使用しています。
|
| Ubuntu 20.04 |
ubuntu-20.04
|
|
| Ubuntu 18.04 [非推奨] |
ubuntu-18.04
|
ubuntu-20.04 または ubuntu-22.04 に移行。 詳しくは、こちらの GitHub のブログ記事をご覧ください。
|
| macOS Monterey 12 |
macos-latest または macos-12
|
macos-latest ラベルは現在、macOS 12 ランナー イメージを使用しています。
|
| macOS Big Sur 11 |
macos-11
|
|
| macOS Catalina 10.15 [非推奨] |
macos-10.15
|
macOS-11 または macOS-12 に移行。 詳しくは、こちらの GitHub のブログ記事をご覧ください。
|
注: -latest ランナー イメージは、GitHub が提供する最新の安定したイメージであり、オペレーティング システム ベンダーから入手できるオペレーティング システムの最新バージョンではない可能性があります。
警告: ベータ版および非推奨のイメージは、"現状のまま"、"保証なし"、"利用可能な状態" で提供され、サービス レベル アグリーメントと保証から除外されます。 ベータ版のイメージは、カスタマー サポートでカバーされない場合があります。
ワークフローログには、ジョブの実行に使用されたランナーが一覧表示されます。 詳細については、「ワークフロー実行の履歴を表示する」を参照してください。
サポートされているソフトウェア
GitHub ホストランナーに含まれているソフトウェアツールは毎週更新されます。 更新プロセスには数日かかり、main ブランチのプレインストール済みソフトウェアのリストは、デプロイ全体が終了した後で更新されます。
プレインストール済みソフトウェア
ワークフローログには、正確なランナーにプレインストールされているツールへのリンクが含まれています。 ワークフローのログでこの情報を見つけるには、Set up job セクションを展開します。 そのセクションの下で、Runner Image セクションを展開します。 Included Software の後のリンクで、ワークフローを実行したランナーにプレインストールされているツールが示されています。
詳しくは、「ワークフロー実行の履歴を表示する」をご覧ください。
各ランナーのオペレーティング システム用に含まれるすべてのツールの一覧については、以下のリンクをご覧ください。
- Ubuntu 22.04 LTS
- Ubuntu 20.04 LTS
- Ubuntu 18.04 LTS (非推奨)
- Windows Server 2022
- Windows Server 2019
- macOS 12
- macOS 11
- macOS 10.15
GitHubホストランナーには、オペレーティングシステムのデフォルトの組み込みツールに加え、上のリファレンスのリスト内のパッケージにが含まれています。 たとえば、Ubuntu と macOS のランナーには、他の既定のツールと共に grep、find、which が含まれます。
プレインストール済みソフトウェアを使用する
アクションを使用して、ランナーにインストールされているソフトウェアと対話することをお勧めします。 この方法には、いくつかの利点があります。
- アクションでは通常、バージョンの選択、引数を渡す機能、パラメータなどの機能が提供されています
- これにより、ソフトウェアの更新に関係なく、ワークフローで使用されるツールのバージョンが同じままになります
要求したいツールがある場合は、actions/virtual-environments で issue を開いてください。 このリポジトリには、ランナーに関するすべての主要なソフトウェア更新に関するお知らせも含まれています。
追加ソフトウェアをインストールする
GitHub ホステッド ランナーに追加のソフトウェアをインストールできます。 詳しくは、「GitHub ホステッド ランナーのカスタマイズ」をご覧ください。
GitHub ホステッド ランナーによって使用されるクラウド ホスト
GitHub は、Microsoft Azure の Standard_DS2_v2 仮想マシン上で GitHub Actions ランナー アプリケーションがインストールされた Linux および Windows ランナーをホストします。 GitHubホストランナーアプリケーションは、Azure Pipelines Agentのフォークです。 インバウンドのICMPパケットはすべてのAzure仮想マシンでブロックされるので、pingやtracerouteコマンドは動作しないでしょう。 Standard_DS2_v2 リソースについて詳しくは、Microsoft Azure ドキュメントの「Dv2 および DSv2 シリーズ」をご覧ください。
GitHubは、GitHub自身macOS Cloud内でmacOSランナーをホストします。
ワークフローの継続性
GitHub Actionsサービスが一時的に利用できなくなっている場合、ワークフローの実行はトリガーされてから30分以内にキューイングされていなければ、破棄されます。 たとえば、ワークフローがトリガーされ、そしてGitHub Actionsサービスが31分以上利用できなければ、そのワークフローの実行は処理されません。
さらに、ワークフロー実行が正常にキューに入れられても、45 分以内に GitHub ホステッド ランナーによって処理されない場合、キューのワークフロー実行は破棄されます。
管理者特権
Linux と macOS のどちらの仮想マシンでも、パスワードレスの sudo が実行されます。 現在のユーザーより高い特権が必要なコマンドやインストール ツールを実行する必要がある場合は、パスワードを入力する必要なく、sudo を使うことができます。 詳しくは、Sudo のマニュアルをご覧ください。
Windowsの仮想マシンは、ユーザアカウント制御(UAC)が無効化されて管理者として動作するように設定されています。 詳しくは、Windows のドキュメントの「ユーザー アカウントの制御のしくみ」をご覧ください。
IP アドレス
注: GitHub の Organization または Enterprise アカウントで IP アドレスの許可リストを使っている場合は、GitHub ホステッド ランナーを使用できず、代わりにセルフホステッド ランナーを使う必要があります。 詳細については、セルフホステッド ランナーに関する記述をご覧ください。
GitHub Actions で GitHub ホステッド ランナーに使われる IP アドレス範囲のリストを取得するには、GitHub REST API を使用できます。 詳しくは、"GitHub メタ情報の取得" エンドポイントの応答で actions キーをご覧ください。
Windows及びUbuntuのランナーはAzureでホストされており、そのためAzureのデータセンターと同じIPアドレスの範囲を持ちます。 macOSランナーはGitHub独自のmacOSクラウドでホストされます。
GitHub ホステッド ランナーには非常に多くの IP アドレス範囲があるため、内部リソースの許可リストとしてこれらを使うことはお勧めしません。
このAPIが返すGitHub ActionsのIPアドレスのリストは、週に1回更新されます。
ファイル システム
GitHubは、仮想マシン上の特定のディレクトリでアクションとシェルコマンドを実行します。 仮想マシン上のファイルパスは静的なものではありません。 home、workspace、workflow ディレクトリのファイル パスを作成するには、GitHub で提供される環境変数を使います。
| ディレクトリ | 環境変数 | 説明 |
|---|---|---|
home | HOME | ユーザ関連のデータが含まれます。 たとえば、このディレクトリにはログイン試行からの認証情報を含めることができます。 |
workspace | GITHUB_WORKSPACE | アクションとシェルコマンドはこのディレクトリで実行されます。 このディレクトリの内容は、アクションによって変更することができ、後続のアクションでアクセスできます。 |
workflow/event.json | GITHUB_EVENT_PATH | ワークフローをトリガーした Webhook イベントの POST ペイロード。 GitHubは、アクションを実行してアクション間でファイルの内容を隔離するたびにこれを書き換えます。 |
ワークフローごとに GitHub によって作成される環境変数の一覧については、環境変数の使用に関する記事をご覧ください。
Dockerコンテナのファイルシステム
Docker コンテナーで実行されるアクションには、/github パスの下に静的なディレクトリがあります。 ただし、Dockerコンテナ内のファイルパスを構築するには、デフォルトの環境変数を使用することを強くお勧めします。
GitHub では、/github パス プレフィックスが予約されており、アクション用に 3 つのディレクトリが作成されます。
/github/home/github/workspace- メモ: GitHub Actions は既定の Docker ユーザー(root) で実行しなければなりません。 Dockerfile でUSER命令が設定されていないことを確認します。されている場合は、GITHUB_WORKSPACEにアクセスできません。/github/workflow
参考資料
- GitHub Actions の支払いを管理する
- マトリックス戦略を使用して、複数のイメージでジョブを実行できます。 詳しくは、「ジョブにマトリックスを使用する」をご覧ください。