使用量をスケーリングすると、 GitHub Actions によってレートが制限される場合���あります。 一部の制限は、 サイト管理者に連絡することで増やすことができます。
特に明記されていない限り、制限に達したときに予想される動作として、ワークフローやジョブの取り消しが挙げられます。
これらの制限は変更されることがあります。
既存システムの制限
| 制限のカテゴリ | 制限 | Threshold | 説明 | サポートをGitHub増やすことは可能ですか? |
|---|---|---|---|---|
| ワークフロー実行制限 | ワークフロー実行時間 | 35 日/ワークフロー実行 | ワークフローの実行がこの制限に達すると、そのワークフローの実行はキャンセルされます。 この期間には、実行時間と、待機と承認に費やされた時間が含まれます。 | |
| ワークフロー実行制限 | ゲート承認時間 | 30 日 | ワークフローは、環境の承認を最大 30 日間待機できます。 | |
| ワークフロー実行制限 | ジョブ マトリックス | 256 ジョブ/ワークフロー実行 | ジョブ マトリックスでは、ワークフロー実行ごとに最大 256 個のジョブを生成できます。 この制限は、 GitHubホストランナーとセルフホステッド ランナーの両方に適用されます。 | |
| ワークフロー実行制限 | 再実行 | 50 回の再実行 | ワークフローの実行は、最大 50 回再実行できます。 この制限には、完全な再実行とジョブのサブセットの再実行の両方が含まれます。 | |
| サポート チケット | ||||
| 小切手 | チェック スイートごとに実行を確認する | 50,000 回のチェック実行/チェック スイート | チェック スイートでは、最大 50,000 回のチェック実行を実行できます。 この制限は、Checks API を使用して作成されたチェック実行およびワークフローチェック実行 GitHub Actions に適用されます。 チェック スイートがこの制限に達した場合、そのチェック スイートに対して追加のチェック実行を作成することはできません。 | |
| サポート チケット | ||||
| ワークフロー キュー | ワークフローのトリガー イベント レート制限 | 1,500 イベント/10 秒/リポジトリ | ワークフロー実行をトリガーするイベントの数には、リポジトリごとの制限があります。 | |
| サポート チケット | ||||
| ワークフロー キュー | キューに登録されたワークフロー実行 | 500 ワークフロー実行/10 秒 | 制限に達すると、Webhook イベントによってトリガーされるはずのワークフロー実行が禁止され、キューに登録されません。 再利用可能なワークフローは、1 つのエンティティと見なされます。 たとえば、30 の再利用可能なワークフローを含む実行は、このインスタンスでは 1 とカウント��れます。 | |
| セルフホステッド | ランナー登録数 | 1,500 ランナー/5 分/リポジトリ/組織/エンタープライズ | ランナーは、リポジトリ/組織/エンタープライズごとに登録できます。 | |
| サポート チケット | ||||
| セルフホステッド | ランナー グループあたりのランナー数 | 10,000 ランナー | ランナー グループごとに同時登録されるランナー数。 | |
| セルフホステッド | ジョブの実行時間 | 5 日 | ワークフローの各ジョブは、最大で 5 日まで実行できます。 ジョブはこの制限に達すると、強制的に終了され、失敗として扱われます。 | |
| セルフホステッド | ジョブ キュー時間 | 24 時間 | ジョブはキューに 24 時間登録されてから、自動的に取り消されます。 | |
| すべての GitHub ホステッド ランナー | ジョブのコンカレンシー | 場合により異なる | ||
| [ | ||||
| GitHubホストされたランナーのジョブ同時実行制限](#job-concurrency-limits-for-github-hosted-runners)を参照してください。 | ||||
| サポート チケット | ||||
| すべての GitHub ホステッド ランナー | ジョブの実行時間 | 6 時間 | ワークフローの各ジョブは、最大で 6 時間まで実行できます。 ジョブはこの制限に達すると、強制的に終了され、失敗として扱われます。 | |
| より大きなランナー | ランナーごとの同時実行制限数 | ランナーの種類によって異なります | ランナーのセットアップ時に設定されます。 通常、Linux CPU ランナーの場合は最大 1,000 ですが、種類によって異なります。 | |
| [ | ||||
| GitHubホストされたランナーのジョブ同時実行制限](#job-concurrency-limits-for-github-hosted-runners)を参照してください。 | ||||
| サポート チケット | ||||
| より大きなランナー | 静的 IP 制限 | 10 個の IP | 企業および組織あたり 10 個の IP。 | |
| サポート チケット | ||||
| より大きなランナー | VNet インジェクション向けプライベート IP 拡張 | 30% バッファー | 予想される最大ジョブ同時実行に対応するためのバッファーが必要です。 | |
| 「大規模ランナーの VNet インジェクション向けプライベート IP 拡張」を参照してください。 | ||||
| 構成可能なAzure仮想ネットワーク | ||||
| 依存関係キャッシュ | 1 分あたりのアップロード数 | 1 分あたり 200 | 各リポジトリは、1 分あたり 200 個のキャッシュ エントリアップロードに制限されています。 この制限を超えた場合、レート制限がリセットされるまで、後続のキャッシュ アップロードの試行は失敗します。 | |
| 依存関係キャッシュ | 1 分あたりのダウンロード数 | 1 分あたり 1500 | 各リポジトリは、1 分あたり 1500 キャッシュ エントリのダウンロードに制限されています。 この制限を超えた場合、レート制限がリセットされるまで、後続のキャッシュダウンロードの試行は失敗します。 | |
| 依存関係キャッシュ | 1 分あたりの削除数 | 1 分あたり 400 | 各リポジトリは、1 分あたり 400 個のキャッシュ削除操作に制限されます。 この制限を超えた場合、レート制限がリセットされるまで、後続のキャッシュ削除の試行は失敗します。 キーまたは ID によってキャッシュを削除する各要求は、この制限にカウントされます。 |
GitHub ホステッド ランナーの ジョブ コンカレンシー制限を参照してください
GitHub サポート** により、**GitHub Actions のジョブのコンカレンシー制限が増加数する可能性があります。 増加を要求するには、サポート チケットを送信します。
| ランナー タイプ | GitHub 計画 | 最大同時ジョブ | 最大同時macOSジョブ | GPU ジョブ同時実行の最大数 | |---|---|---|---|---| | 標準 GitHub ホステッド ランナー | Free | 20 | 5 | 適用なし | | 標準 GitHub ホステッド ランナー | Pro | 40 | 5 | 適用なし | | 標準 GitHub ホステッド ランナー | チーム | 60 | 5 | 適用なし | | 標準 GitHub ホステッド ランナー | Enterprise | 500 | 50 | 適用なし | | より大きなランナー | チーム | 1000 | 5 | 100 | | より大きなランナー | Enterprise | 1000 | 50 | 100 |
メモ
最大同時 macOS ジョブは、標準の GitHubホストランナーと GitHubホスト型の大規模ランナー間で共有されます。
すべての GitHub ホステッド ランナーの記憶域の制限
GitHubサポート**では、**GitHub Actionsのストレージ制限を増やすことはできません。
| Plan | アーティファクト ストレージ | 分 (月あたり) | キャッシュ ストレージ (リポジトリごと) | カスタム イメージ ストレージ |
|---|---|---|---|---|
| GitHub Free | 500 MB | 2,000 | 10 GB | 適用なし |
| GitHub Pro | 1 GB | 3,000 | 10 GB | 適用なし |
| GitHub Free 組織向け | 500 MB | 2,000 | 10 GB | 適用なし |
| GitHub Team | 2 GB | 3,000 | 10 GB | 75 GB |
| GitHub Enterprise Cloud | 50 GB | 50,000 | 10 GB | 150 GB |
より大きなランナーの VNet インジェクションのプライベート IP 拡張
VNet インジェクションでより大きなランナーを使うときは、適切なサブネット IP アドレス範囲を決める必要があります。その場合、予想されるジョブ同時実行最大数にバッファーを追加することをお勧めします。 たとえば、ネットワーク構成のランナーが、300 のジョブ同時実行最大数に設定されている場合は、少なくとも 390 ランナーに対応できるサブネット IP アドレス範囲を使用します。 Azureでは、すべてのサブネット (最初の 4 と最後の 1) に 5 つの IP が予約され、ランナーの要件に応じて最小限の実用的なサブネット サイズが設定されることに注意してください。 非常に小さいサブネット (/29 以下など) では、ニーズに十分な使用可能アドレスが提供されない場合があります。
一般的なヒットに依存するサービスの制限
GitHubの REST API レート制限 は、 GitHub Actions ユーザーに適用されます。一般的にヒットするユーザーは次のとおりです。
-
認証されていないユーザー-パブリック データのみをフェッチする場合は、認証されていない要求を行うことができます。 認証されていない要求は、要求を行ったユーザーまたは申請ではなく、発信元の IP アドレスに関連付けられます。
認証されていない要求のプライマリ レート制限は、1 時間あたり 60 要求です。
-
認証済みユーザー-personal access token を使用して API 要求を行うことができます。 さらに、GitHub App または OAuth app でも、次にユーザーに代わって API 要求を行うことができます。
これらの要求はすべて、1 時間あたり 5000 件の個人的レート制限に向けてカウントされます。
-
GitHub アプリのインストール-インストール アクセス トークンを使って認証された GitHub Apps は、インストールの最小レート制限である 1 時間あたり 5,000 要求を使います。 GitHub Enterprise Cloud organization 上のインストールの場合、インストールには 1 時間あたり 15,000 要求というレート制限があります。
GitHub Enterprise Cloud organization 上ではないインストールの場合、インストールのレート制限はユーザーとリポジトリの数に応じてスケーリングされます。 20以上のリポジトリを持つインストールでは、リポジトリごとにⅠ時間あたり50リクエストが追加されます。 ユーザー数が 20 人を超える組織のインストールでは、ユーザーごとに 1 時間あたり別の 50 要求を受け取ります。 レート制限は、1 時間あたり 12,500 要求を超えて増やすことはできません。
GitHub App ユーザー アクセス トークンのプライマリ レート制限 (インストール アクセス トークンとは対照的) は、認証されたユーザーのプライマリ レート制限��よって決まります。 このレート制限は、別の GitHub App または OAuth app がそのユーザーに代わって行う要求と、ユーザーが personal access token で行った要求と組み合わされます。 詳しくは、「REST API のレート制限」をご覧ください。
-
OAuth アプリ
-
GITHUB トークン-
GITHUB_TOKENのレート制限は、リポジトリごとに 1 時間あたり 1,000 要求です。GitHub Enterprise Cloud アカウントに属するリソースへの要求では、制限はリポジトリごとに 1 時間あたり 15,000 要求です。 -
2 次レート制限- プライマリ レート制限に加えて、 GitHub では、不正使用を防ぎ、すべてのユーザーが API を使用できるようにセカンダリ レート制限を適用します。これらは GHEC では構成できません。 詳しくは、「REST API のレート制限」をご覧ください。
GitHub Actions のDocker Hubのレート制限
- ** パブリック イメージをプルする GitHub ホステッド ランナー: ** Docker Hub のレート制限は適用されません。
- GitHub ホストランナーがプライベート イメージをプルする: Docker Hubからのプライベート イメージのプルにはレート制限が適用されます。
- パブリックイメージまたはプライベートイメージをプルするセルフホステッド ランナー: Docker Hubからのイメージのプルには常にレート制限が適用されます。